[LAU] JACK2 hardware buffer size for browser-based video conferencing

[Andrew A. Grathwohl]

Hi David,

Thanks this was super-informative!

We can likely rule out the idea that the smaller buffer sizes tax the
computer further, leading to more fan/PSU noise, since the machine
itself is not in the same room as the microphone.

I am intrigued by your comments about the sampling rate on my Babyface
Pro. I have always set it to 48kHz whenever doing low-latency audio or
any audio that will be transmitted over a network cable, which I mostly
do superstitiously. Is there any guidance out there about what the
correct sampling rate would be for my device, or about how to determine
this answer for myself?

Best,
    AG

On 1/3/21 2:49 PM, David Kastrup wrote:
> "Andrew A. Grathwohl" <andrew at grathwohl.me> writes:
>
>> Hi folks,
>>
>>     I have a question about my microphone audio quality when
>> participating in a browser-based video conference, i.e., Google Meet and
>> Jitsi on chromium browser.
>>
>>     Starting last week, I have received numerous reports from coworkers
>> that my audio is considerably higher quality than normal. Although my
>> audio input has always been a high end vocal mic, the reports have
>> indicated that I sound even better than I usually do in these conferences.
>>
>>     My daily driver machine is a self-built Xeon workstation running
>> Arch Linux with (I think) a well-configured RT kernel and JACK2, whose
>> configuration if optimized for USB audio interfaces via this guide
>> <https://wiki.linuxaudio.org/wiki/list_of_jack_frame_period_settings_ideal_for_usb_interface>
>> [0]. I use a Peluso mic connected directly to my RME Babyface Pro
>> interface, which is running via one of my system's USB2 ports.
>>
>>     In pursuit of understanding why this is occurring, I looked at my
>> JACK2 settings to see if I'd changed anything lately. Sure enough, I
>> noticed that I have been working at a larger JACK2 hardware buffer size
>> than normal. I typically set my size to 64 since I do a lot of real-time
>> audio work, but have had it set to 256 or 512 lately to do some
>> different kinds of stuff on the system.
>>
>>     So, my question boils down to: is it reasonable to suspect the
>> hardware buffer size has something to do with these sudden quality
>> improvement reports from my friends & co-workers? If so, any insights
>> into why this is the case would be greatly appreciated.
> The question is whether they are mixing up audio quality and connection
> quality.  Larger buffer sizes may reduce the likelihood of dropout.
> They don't really do much else.  However, a small buffer size may tax
> your computer much more, leading to more noise from the power supply
> and/or the computer fan.  Depending on where your microphone is
> positioned, that can really make a difference.
>
> Another, less likely, source of difference may be a change of sample
> rate.  Having something like the Babyface Pro work at the correct final
> sample rate is likely to be a very good compromise between latency and
> quality.
>
> And one thing not to underestimate is that they may attribute a change
> elsewhere to quality from you: I remember a Jitsi session where
> everyone's audio was plagued with echoes except for one that came across
> fine, from a Mac mini user.
>
> Guess whose computer was actually responsible for messing up everyone's
> audio with echoes...
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/linux-audio-user/attachments/20210105/912bd627/attachment.html>