Technical comparison with Sonobus

[j-santander]

To give a bit of context. I'm part of a choir which is using jamulus for some of its rehearsal sessions.

Most of the people is non technical, but, so far and after some rough starts, we're doing mostly ok and it is starting to feel like singing in a choir.

Perhaps the key learning point is that a session success depends critically on the absence of "bad participants" (people with bad connections, bad headphones/microphone or simply insufficient knowledge of what we're singing). To minimize those problems we had to resort to limiting the number of people per session (as more people involved increases the possibility of a "bad participant" presence).

We're now trialing Sonobus. So far the observations (consensus of the people participating) are:

• Sound quality is better.
• It was very easy to set up.
• And it seems to work well over WiFi and mobile devices.

Technically and on the surface, the main difference seem to be that Sonobus uses All-to-All connections (i.e. there's no mix server, all participants connect to everyone and the mix you hear is created locally).

I guess this peer-to-peer connection works towards the simplicity of the setup. In jamulus we spent a lot of time solving issues with the servers until we finally settled on an externally hosted server on Internet.

However, this use of peer-to-peer connections means that there seems to be a number of people in the session that cannot connect to others. I suspect that trying to roll it out for the whole choir could mean a support nightmare of network operators/router vendors and setup combinations and trying to explain people how to do port forwarding.

The thing that intrigues me more is the "better quality" and "working well over wifi", in case there's something to learn and include back into Jamulus.

I don't have hard numbers or measurements to back up those affirmations and it might be simply people deluding themselves with a new toy.

From what I gather, both Jamulus and Sonobus use fundamentally the same approach:

• Use UDP to send data without delays and retransmissions.
• Use a Jitter Buffer on reception to reorder and smooth out jitter.

In the case of Jamulus is its own protocol. In the case of Sonobus they use this Audio over OSC (forked). From what I've gathered, OSC is something in the same space as MIDI, but AOO seems to have hijacked some formats and syntaxis of OSC to create a protocol for audio transmission.

There seem to be some "resampling" that works towards hiding timing differences. Messages have sequence numbers and it seems that they could overlap (i.e. sending half a block in one packet and repeating it in the next).

Not sure, overall there seems to be few detailed technical information.

[dcorson-ticino-com]

Thanks for this information.
It would help us if you gave us some more data.
What sound quality setting are you using for Jamulus and what sound quality setting for Sonobus?
Have you measured the amount of data sent?

My use of Sonobus has been pretty limited because every time I used it it crashed after a while, but I did notice that with the better sound quality settings one is quickly over 1Mb/s for each user connected. For big groups that will be very limiting as every user needs to provide that speed at their connection.

But my problem with peer-to-peer programs such is Sonobus is another. That is that there is no synchronization between the users. Everyone hears something else depending on the ping times they see to the other users. If there are few users and they have very low ping times all will be well. But for bigger groups and more widely varying ping times that will make playing synchronization impossible as what one person hears as synchronous will not be what another hears as synchronous.
Jamulus' server provides a synchronizing point so that everyone hears the same signal. If you adjust your singing/playing to be synchronous with someone else everyone else on the server will also hear it as synchronous. Thus it is possible for a whole group to play together synchronously despite their varying ping times.

In any case, please continue to inform us about your experiences. We can certainly learn from each other, the more the better.

(As an aside: I find it interesting that I have rarely heard groups playing music on Sonobus, I hear just groups talking about Jamulus. But maybe all the music making is happening on private groups, I don't know.)

[j-santander]

Thanks for your insights.

As I said, I don't currently have any hard data, just the opinions expressed by the rest of the people participating.

I'll try to take some measurements next time and pay attention to the quality settings of the people (Sonobus does have a setting to use PCM, but I could swear people was using the Opus codec).

Thanks for pointing out too additional concerns about peer-to-peer topology (bandwidth and multiple synchronization points). It is clear that for scalability, a central server setup it is much better. What I was thinking is that if Sonobus can be perceived as better quality or whether it is more reliable in a network less deterministic in latency as WiFi could be because they have some nice trick either in the encoding or in the jitter buffer/synchronization code.

Otherwise, my secondary intent was mostly to a) see if someone had already looked into that and b) learn more about the internal working of jamulus and sonobus.

[gene96817]

@j-santander It would be good for you to report in on how quality varies with number of participants. I am especially interested in whether there is a size where, as you add participants, it becomes harder to maintain the quality of experience. For example, "the experience is great with 6 participants and as we add people beyond that point, ..." Maybe the number is 10? or 20? or 50? Thanks.

[npostavs]

I'll try to take some measurements next time and pay attention to the quality settings of the people (Sonobus does have a setting to use PCM, but I could swear people was using the Opus codec).

My experience is that compression effects are quite obvious when setting the bitrate below 48kbit/s, but otherwise it's really not noticeable.

[ann0see]

In theory you could even talk to the SonoBus developer/point him to this thread since it's also FLOSS as far as I know

[j-santander]

Certainly, let me try to do that.
@sonosaurus, we've started this thread to discuss and compare aspects of the design and implementation of jamulus and sonobus in the hope that the information gathered could be benefitial to both.

[ann0see]

Ok. I'll also mention another collaborator.

[ann0see]

Hi @essej
You're pinged from the Jamulus discussion forum, and I hope that's ok for you.

we've started this thread to discuss and compare aspects of the design and implementation of jamulus and sonobus in the hope that the information gathered could be benefitial to both.

[BentWrench]

I play drums and tried Sonobus. The issue for me was lag (latency) and the inability to stay on beat. There is a metronome built-in to Sonobus and tried using it but it didn't really help. The situation was similar to joining a Jamulus server with a very high ping time, anything over about 20ms ping and 40ms total connection latency is not good. So I run my own server over my home fiber-optic internet and that works great for me and my other band mates. If someone with a high-latency connection joins the server, it doesn't ruin the whole jam for me, where in Sonobus, that was the opposite of my experience, if someone with high latency joins it immediately ruins the session. Now granted I don't have a tone of experience just a couple hours of trial and error. But at this point Jamulus provides the better, more predictable experience.

[npostavs]

The thing that intrigues me more is the "better quality" and "working well over wifi", in case there's something to learn and include back into Jamulus.

I didn't try using it over wifi, but my sense is that Sonobus tends to trade-off higher latency for better sound quality relative to Jamulus.

[gene96817]

I would wait to hear the number of participants. It is easier to have a better-X in a small setting. The demands on resources in a peer-to-peer network grows by n^2. It is a world of difference or a group of 6 or a group of 12.

[npostavs]

Yes, but I found even playing one-on-one that Sonobus gets higher latency (which surprised me, since my initial expectation would be that peer-to-peer should have an advantage in that situation). I think at least part of the issue is that Sonobus' auto mode chooses larger buffers. Since the other people I'm playing with aren't very technical, I'm not sure how much this can be compensated for by manual settings.

[dcorson-ticino-com]

I am intrigued by the comments that Sonobus is easier to set up.
I see, however, no difference between our client setup and theirs.
(Yes we have servers, but that is not a problem for the clients)
When reading their documentation I see they have the same problems with setup as we do and mention the same solutions.
One must also decide on the quality of the connection for every user connected, making it more work than we have.
Why is it that people seem to think that Sonobus is easier to set up ?
What can we do do give people the good feeling that Jamulus is easy to set up?

[ann0see]

Do they also need ASIO4ALL? Maybe they have a better UI?

I think one disadvantage of Jamulus is that it only supports 48kHz devices and doesn't handle 44.1 kHz devices in an user friendly way: select a device which doesn't support 48kHz in ASIO4ALL --> receive a fatal error which results in Jamulus being closed.

[dcorson-ticino-com]

Yes they do use ASIO4ALL, but they do have resampling for 44.1k.

[j-santander]

I'm mostly relaying the comments from the people in both topics (quality and easy to set up).

Regarding the set up. One possible explanation is that the people participating in the trial are all Jamulus "veterans" and they probably remember the rough ride we had until we settled into our current Jamulus configuration.

In Windows, my client shows as possible Audio device types:

• Windows Audio
• Windows Audio (Exclusive mode)
• Windows Audio (Low latency mode)
• ASIO

Regarding the UI and highlighting a few things that might be of interest:

• Big button to connect
• Button to quick access the audio setup before connection.
• They do have an input level control (e.g. Client: Add support for input gain control #1222)
• They have an output level control (meaning overall volume).
• Participants are layed out horizontally instead of vertically (not that it should not really matter).
• They lack a chat
• They lack the grouping of users to move faders in sync.

[npostavs]

Like j-santander said, Sonobus supports ASIO, but there is support for non-ASIO devices as well, so ASIO4ALL is not needed. This makes it much easier for Windows users to set things up with builtin sound cards.

[ann0see]

Since you're working on non-ASIO support, I think Jamulus will soon also support "Windows Audio"

[olibac]

I play drums and tested JamKazam, Sonobus and Jamulus. My experience was similiar to @RobVM1.
I use Sonobus and JamKazam to jam with other people in public groups, the goal of the jam is just fun, I mean it's not very important what I play or with whom or the sync with other members (if I am in sync with a couple of members is ok for me). But only with Jamulus was possible to work on a real rehearsal almost as we were in the same room. I am running my own server and client in the same laptop (Lenovo T460) and it works pretty well.

A for Sonobus I tested with my band mates because the audio quality seems better, you don't usually get pops and waverly sounds. The problem for us with Sonobus was latency. In my case I was hearing almost every member in different times, first guitar, then bass and finally the singer...It was difficult to play in time. We used PCM 16 quality audio to decrease in 5ms (roundtrip) the latency (decompression takes about 2.5ms). We live in the same town so I really did not understand why the experience was so bad. So happily we stick to Jamulus :).
We also tested Sonobus because of routing options. If you use VST version every member can be mapped to a track in a DAW, so you can add FX (compression, deesser, eq...), this is very convenient if your intention is to stream a virtual gig, gives the person who is mixing more control over what and how is sent to the stream. I opened #1306 (merged with #967) as an idea to improve this.

I agree with @dcorson-ticino-com about configuration...for me is the same thing in Sonobus and Jamulus, select Device and inputs/outputs, configure ASIO...

As a general rule with peer to peer the least members in a group the better. But you can have a good session with 10 members and bad session with 5 members, I guess because the way peer to peer works.

You can find just a few public groups in Sonobus, so almost everything is happening in private groups (at least when I connect, I live in Barcelona, Spain).

[j-santander]

A for Sonobus I tested with my band mates because the audio quality seems better, you don't usually get pops and waverly sounds.

Actually, that's kind of my point. What sonobus does differently in the encoding and jitter buffer that causes this perceived better quality and that jamulus could use?

The answer is probably to code review both, but I'll have to set time for that.

Bandwidth, resource usage and sync drift concerns on sonobus are caused likely by the peer-to-peer topology

[npostavs]

A for Sonobus I tested with my band mates because the audio quality seems better, you don't usually get pops and waverly sounds. The problem for us with Sonobus was latency.

I had similar experience. How much did you guys try adjusting the buffers in Sonobus?

.for me is the same thing in Sonobus and Jamulus, select Device and inputs/outputs, configure ASIO...

If you have an audio interface with its own ASIO drivers then Jamulus setup is pretty okay.

[atsampson]

We live in the same town so I really did not understand why the experience was so bad.

This is such a common misconception that I think it might be worth discussing in the intro documentation. How close players are physically only has a very loose relationship to how close they are in terms of Internet routing.

For example, in the UK, many ISPs use a separate "backhaul" network to get from the user's local telephone exchange to one of the big London datacentres, and then connect to the rest of the Internet there - so two random users in the same city in Scotland will typically have a route between them that goes via London, 400km away.

[olibac]

I agree. But I would expect if Jamulus is working quite well, Sonobus will work well too. In our case it was not the case. We could not play together in Sonobus, close it, open Jamulus and play.

[olibac]

One of the things that can explain "quality of sound" seems to be better in Sonobus is about how you are hearing yourself. I mean, the first time I tested Sonobus (JamKazam too) I was alone in a private test group and the first thing I noticed was "I hear myself better". In my opinion it was because of two things a) the quality of sound b) no latency.
I supose, as no server involved, Sonobus delivers local input to local output (so its not adding latency, or it is not noticable). For the same reason quality of sound is not altered as well.

[dcorson-ticino-com]

as no server involved, Sonobus delivers local input to local output

I hadn't thought of that, another reason why, as we all know, it is not possible to play in sync if there is any delay.
I have heard people using Jamulus say singers should mute themselves, but that eliminates any possibilities of doing corrections to play really together. In the end really self-defeating.

[pjjackman]

I'm really pleased that j-santander has started this discussion. I would like to use Jamulus more, as I am currently paying for a privately-hosted server subscription, however the audio quality of SonoBus is superior in my experience. It's most-noticeable when using a stereo microphone and acoustic guitar. Jamulus seems to have trouble keeping the left and right channels time-aligned after dropouts resulting in what sounds like a constantly changing frequency response due to the phase shifts. Pluck a single string and just let it decay; repeat. The D or G string is best. Hopefully you'll hear what I'm describing. It sounds like the low frequencies "pop" in and out of a flat, full-spectrum response. This phase shifting can also be heard with client and server on the same box although with fewer dropouts it's harder to reproduce. It happens for me on Windows, Apple and Linux OSs.

I experience none of this with Sonobus; recording at PCM 24 bit with another local guitarist feels like being in different iso booths at the same studio. I was hoping the Jamulus team knew about this issue and was working on a remedy for the 3.7.0 release.

[BentWrench]

I think I have experienced what you're talking about. I play my drums on my server alone occasionally and at times I hear my drums change pitch, seemingly out of the blue. I doubt there is an easy fix for this, and it seems any major change to the audio processing could possibly break backwards-compatibility, something I think the project works to avoid.

[dcorson-ticino-com]

I experience none of this with Sonobus; recording at PCM 24 bit

I hope you do realise that you are comparing apples with oranges.
The best quality for Jamulus has less than 500kbs the 24 bit PCM is over 1.2Mbs. There is no way that Jamulus can keep up with that and there will be many users who have connections that can't keep up.
Yes, Jamulus is looking to increase the quality in the future for those who can avail themselves of it. But at the moment the idea is to be as inclusive as possible.
I also note that I have heard such things when using low and normal quality, but never with high.

Can you give any idea of the latency times of Sonobus compared to Jamulus? I have the impression that the delay times are significantly greater for Sonobus, but as it keeps crashing on me it is hard to measure.

[pjjackman]

The Jamulus audio artifact I am describing seems to be independent of Quality setting but I experience it when set at High. It will also appear with a buffer size as large as 128 samples; I just confirmed this.

In terms of latency comparisons, with a local pal in Vancouver we get 10 - 15 ms round trip with SonoBus. The private Jamulus server I use is in Seattle, because the path to there was more stable than to a local server with the same company (ping 4 - 6 ms). I get 15 - 20 ms overall on that circuit (64 samples, jitter 2/2). SonoBus has lower latency in my experience and has never crashed.

The subjective quality that SonoBus delivers for me is a consistent frequency response that is largely free of pops.

[ghost]

@pjjackman

It's most-noticeable when using a stereo microphone and acoustic guitar. Jamulus seems to have trouble keeping the left and right channels time-aligned after dropouts resulting in what sounds like a constantly changing frequency response due to the phase shifts. Pluck a single string and just let it decay; repeat. The D or G string is best. Hopefully you'll hear what I'm describing. It sounds like the low frequencies "pop" in and out of a flat, full-spectrum response. This phase shifting can also be heard with client and server on the same box although with fewer dropouts it's harder to reproduce. It happens for me on Windows, Apple and Linux OSs.

This made me think of a question for the Jamulus developers in particular:
How does Jamulus deal with the differing sample frequencies (48000 Hz +/- crystal frequency tolerance)?
Do samples accumulate (overflow/underflow) until things "pop" back into alignment?
Maybe this is the problem with #1059

Edit:
The issue here is that @pjjackman brought up a symptom that will probably lead to a simple solution for many problems (#1059, which I have no interest in, will probably evaporate without anyone knowing what happened).
Also, #1313 will be resolved.

[gene96817]

I leave others to examine the sound fidelity and codec issues.

My general rule of thumb is "work is conserved". Given N musicians, the same functions have to be provided. You can choose peer-to-peer or a peer-server architecture, the same work as to be done. When I hear "my bandmates", I hear two clues. (1) this is a small group, say 3-5, musicians. This is a long way from a chorus (e.g. 30+). (2) this is a small sample of like-minded users. It is likely they all have clean Internet connections. The uniform experience gets more diverse with more users. I really want to hear about the experience of at least a mid-size group. Since the complexity of some P2P parameters grow by N^2, I really want to hear about the band size, especially where N > 10.

Now I am really interested in hearing about opportunities for improving Jamulus sound handling.

[dakhubgit]

Now I am really interested in hearing about opportunities for improving Jamulus sound handling.

A meta-opportunity would be refactoring the sound handling to a degree where one concept is implemented and handled in one localised and identifiable place. That's sort of the main reason to buy into C++' enormous language complexity: being able to modularise without stopping at the function call boundary.

Before improving Jamulus sound handling, you need to be able to understand and review it in a recognizable manner. Now of course this sounds a bit like "we need to accommodate more armchair theorists". But in the end, Jamulus is maintained by volunteers, and if they spend all of their spare time understanding the existing code, they won't have time to experiment with new approaches. And when stuff is open-coded throughout, experimenting with new approaches becomes a lot harder, too.

[essej]

Hello, I'm the main developer of SonoBus. Since Jamulus and SB both use Opus, I too am curious why people seem to hear SonoBus as having higher audio quality overall, and I have a few theories.

First, currently SonoBus (via AOO) is using the standard multichannel opus encoder and not the custom encoder that Jamulus uses. Here is a section of the Opus docs from the Custom section: https://www.opus-codec.org/docs/html_api-1.0.2/group__opus__custom.html

Opus Custom is an optional part of the Opus specification and reference implementation which uses a distinct API from the regular API and supports frame sizes that are not normally supported. Use of Opus Custom is discouraged for all but very special applications for which a frame size different from 2.5, 5, 10, or 20 ms is needed (for either complexity or latency reasons) and where interoperability is less important.

In addition to the interoperability limitations the use of Opus custom disables a substantial chunk of the codec and generally lowers the quality available at a given bitrate. Normally when an application needs a different frame size from the codec it should buffer to match the sizes but this adds a small amount of delay which may be important in some very low latency applications. Some transports (especially constant rate RF transports) may also work best with frames of particular durations.

Since SonoBus doesn't use the custom encoder, it will only use the minimum 2.5ms (120 samples) frame size when the native processing block size is low, thus incurring a small buffering delay when other frame sizes are used for audio processing. But I bolded the sentence that I wonder is part of the issue... it's unclear exactly what "chunk of the codec" is disabled, and what quality losses occur when using the custom encoder.

The other aspect of P2P vs server based, is that with P2P each party gets separate opus encoded stream from each player, vs one mixed audio stream for the server-based... the encoder has a bit of an easier job because the content is less complex (single instrument vs full mix, etc). Also, there is one less encode-decode step in the chain. I don't know how much this affects it.

The third thing, is due to the potentially larger jitter buffers that SB needs due to implementation issues, there are probably fewer network underruns and thus fewer disruptions to the audio (where opus has to go into drop mitigation mode, etc).

Going forward, I'll be working with the AOO developer to see if we can make some improvements to low-latency performance... and some of that may be attempting to use the same custom encoder options that Jamulus is... and maybe then we'll see if that is a source of the quality differences.

[npostavs]

The other aspect of P2P vs server based, is that with P2P each party gets separate opus encoded stream from each player, vs one mixed audio stream for the server-based... the encoder has a bit of an easier job because the content is less complex (single instrument vs full mix, etc). Also, there is one less encode-decode step in the chain. I don't know how much this affects it.

I think this is at most a very minor effect, because the quality difference is noticeable in recordings made by the Jamulus server. The server records the streams separately into 1 .wav file per client before the mixing and re-encoding happens, so in terms of encoding steps and complexity it's in the same situation as SonoBus.

The other two things you mention seem plausible to me. Especially the larger buffer; the main reason I don't use SonoBus is that the latency is noticeably worse than Jamulus. (The other reason is that I sometimes play with people whose bandwidth isn't sufficient for multiplayer P2P)

[j-santander]

Thanks @essej, first of all for participating in this discussion, and second for your insight.

I'll try to find time to do some experimenting on jamulus side.

[npostavs]

I'll try to find time to do some experimenting on jamulus side.

I've tried to do this experiment, but I failed to get it working. Follow-up in #1920 if anyone is interested.

[jp8]

curious why people seem to hear SonoBus as having higher audio quality overall

I assumed this was because Jamulus audio goes through the codec twice (once up to the server, and again, down from the server). Sonobus audio reaches its destination with a single trip through the codec.

[dakhubgit]

essej ***@***.***> writes:

Hello, I'm the main developer of SonoBus. Since we both use Opus, I too am curious why people seem to hear SonoBus as having higher audio quality overall, and I have a few theories. First, currently SonoBus (via AOO) is using the standard multichannel opus encoder and not the custom encoder that Jamulus uses. Here is a section of the Opus docs from the Custom section: https://www.opus-codec.org/docs/html_api-1.0.2/group__opus__custom.html > Opus Custom is an optional part of the Opus specification and > reference implementation which uses a distinct API from the regular > API and supports frame sizes that are not normally supported. Use of > Opus Custom is discouraged for all but very special applications for > which a frame size different from 2.5, 5, 10, or 20 ms is needed > (for either complexity or latency reasons) and where > interoperability is less important. > > **In addition to the interoperability limitations the use of Opus > custom disables a substantial chunk of the codec and generally > lowers the quality available at a given bitrate**. Normally when an > application needs a different frame size from the codec it should > buffer to match the sizes but this adds a small amount of delay > which may be important in some very low latency applications. Some > transports (especially constant rate RF transports) may also work > best with frames of particular durations. Since SonoBus doesn't use the custom encoder, it will only use the minimum 2.5ms (120 samples) frame size when the native processing block size is low, thus incurring a small buffering delay when other frame sizes are used for audio processing. But I bolded the sentence that I wonder is part of the issue... it's unclear exactly what "chunk of the codec" is disabled, and what quality losses occur when using the custom encoder.

Maybe custom tables?

Going forward, I'll be working with the AOO developer to see if we can make some improvements to low-latency performance... and some of that may be attempting to use the same custom encoder options that Jamulus is... and maybe then we'll see if that is a source of the quality differences.

Jamulus uses either 128 sample or 64 sample Opus. The main point it tries to achieve is matching the buffer size of the soundcard I think. My personal opinion is that this is a mistake. Here's why: a) 64/48kHz = 4/3 ms which is a bad unit for a timer, and the server runs by timer loop. In contrast, 120/48kHz = 2.5 ms . b) Packets are not self-describing which means that any change in parameters has to be synchronised with the transmission of such parameters. On the plus side, packet _size_ is one such parameter that could be implicitly used. Jamulus, however, only uses it for deciding whether arriving packets are data packets or signaling packets and drops anything of unexpected size, making it unsuitable for VBR. The Opus self-description is not actually costly. c) Jamulus has an option to record input. It records it as WAV. Using a standard Opus frame would mean it could just dump the Opus frames, being faster, and not wasting storage on information that wasn't there before unpacking into WAV. d) soundcard drivers (at least the ASIO ones) actually tend to go for (power of 2) multiples of 24 samples (0.5 ms) e) (forward-looking:) WebRTC is recognised Internet infrastructure and packages standard Opus. Using the protocol would likely make Jamulus packets be transported more consistently. Whether it makes sense to use the libraries, too, depends on whether one can configure them well enough to make them increase latencies only in emergency situations. The amount of effort Jamulus invests into squeezing out milliseconds is not matched by the quality of the code base and the programmer power available for maintaining it. That makes the advantages more theoretical than actually available in a dependable manner. I've not dabbled all that long with Jamulus, so my opinion may be comparatively unqualified or untainted (pick your favorite characterisation).

…

-- David Kastrup

[npostavs]

d) soundcard drivers (at least the ASIO ones) actually tend to go for (power of 2) multiples of 24 samples (0.5 ms)

I agree with most of your points, but I don't think this one is true. The docs for ASIOGetBufferSize say "Usually, the buffer size will be a power of 2", with nothing about multiples of 24. My Motu M2 allows these sizes:

[Martin-SF]

a) 64/48kHz = 4/3 ms which is a bad unit for a timer, and the server
runs by timer loop. In contrast, 120/48kHz = 2.5 ms .

I think you meant 128/48kHz and not 120 which doesnt change the fraction problem you mentioned because the denominator stays 3. Its for every power of 2 the same

The docs for ASIOGetBufferSize say "Usually, the buffer size will be a power of 2", with nothing about multiples of 24.

My ZOOM UAC-2 uses buffersizes by the row 32*n (32, 64, 96, 96, 192...). Here with 96 it even goes 96 samples / 48kHz = 2.0 ms

[dakhubgit]

Noam Postavsky ***@***.***> writes:

> d) soundcard drivers (at least the ASIO ones) actually tend to go for (power of 2) multiples of 24 samples (0.5 ms) I agree with most of your points, but I don't think this one is true. The docs for `ASIOGetBufferSize` say "Usually, the buffer size will be a power of 2", with nothing about multiples of 24. My Motu M2 allows these sizes: 

OK. I'll admit that my sample size had been 2, so I might have been a bit too eager in overgeneralising it :)

…

-- David Kastrup

[ann0see]

Not 100% related, but I thinking could be worth publishing an article on the KB how to link SonoBus and Jamulus. This might allow people to listen/join by phone.

[gilgongo]

Just a quick mention of this wikipedia page if anyone interested in comparative information between Jamulus, Sonobus or other systems wants to make sure it's up to date.

[dakhubgit]

Martin Schönfeld ***@***.***> writes:

> a) 64/48kHz = 4/3 ms which is a bad unit for a timer, and the server > runs by timer loop. In contrast, 120/48kHz = 2.5 ms . I think you meant **128**/48kHz and not **120** which doesnt change the fraction problem you mentioned because the denominator stays 3. Its for every power of 2 the same

I meant exactly what I wrote. Obviously if you nilly-willy change the numbers, the results become wrong and my post wouldn't have made sense in the first place.

> The docs for ASIOGetBufferSize say "Usually, the buffer size will be > a power of 2", with nothing about multiples of 24. My ZOOM UAC-2 uses buffersizes by the row 32*n (32, 64, 96, 96, 192...). Here with 96 it even goes 96 samples / 48kHz = 2.0 ms

The sound card buffer size has comparatively little to do with the timer loop shuffling data to and from the network (and the server) since there is intermediate buffering.

…

-- David Kastrup