Setting Direct ALSA Sample Rate

[lplassman]

When using an audio interface with the ALSA backend, and trying to set a sample rate of anything other than 48000, resampling occurs and the audio interface is never actually set to the given sample rate. Is there any way to force the sample rate to an ALSA device, so that software resampling doesn't have to occur?

[khiner]

I’ve also seen this behavior on CoreAudio. Configuring a non-default sample rate always seems to result in sample-rate conversion, even if both input and output devices natively support the SR.

[mackron]

This is different to the ALSA case. When I wrote the Core Audio backend I was not able to figure out a simple way to configure Core Audio to do sample rate conversion. The only way I could figure out how to do it involves having to change the sample rate on the OS itself (as in, it'll change the sample rate in your audio settings). I deemed this was to disruptive to enable by default, so it needs to be explicitly enabled via the device config:

deviceConfig.coreaudio.allowNominalSampleRateChange = MA_TRUE;

[khiner]

Thanks for the explanation! I’ll look into trying this out if needed.

[mackron]

I disabled ALSA-level resampling years ago due to a bug somewhere. It was related to memory mapping mode which miniaudio isn't currently using, so perhaps I can relax that. I'll need to experiment with it. If you care about my explanation, you can do a search for ((ma_snd_pcm_hw_params_set_rate_resample_proc)pDevice->pContext->alsa.snd_pcm_hw_params_set_rate_resample)(pPCM, pHWParams, 0); in miniaudio.h and read the comment there. As an experiment you could try commenting out that line and see what happens - I'll be curious to hear how that works for you.

Having said all that, the requested sample rate is indeed set in the hardware parameters so if your device has native support for a given sample rate I would expect that sample rate to work. I don't have an explanation if that's not working for you.

[lplassman]

Ok, so I found several interesting findings regarding this issue. For reference, I am using a M-Audio M-Track Duo audio interface for these tests. This particular interface is advertised as supporting both 48kHz and 44.1kHz sample rates (I also verified these rates by running this command: cat /proc/asound/card1/stream0)

First, I tested setting the miniaudio sample rate to 48000 with a periodSizeInFrames of 480. The sound quality was perfect with no stutters or skipping, although the buffer size seemed incorrect. Here is the debug output from miniaudio:

Next, I tested setting miniaudio to a sample rate of 44100 with the same period size. Resampling was enabled according to the debug output, and sound would skip and jump forward every ten seconds. Latency was also quite noticeable in this configuration (about 0.4 seconds). Here is the debug output:

For the next test, I edited the default alsa configuration file at: /usr/share/alsa/alsa.conf and changed the line defaults.pcm.dmix.rate from 48000 to 44100. The miniaudio sample rate was still set to 44100 with the same period size of 480. The audio card actually switched from 48kHz to 44.1kHz and the audio quality was perfect (no resampling). Here is the debug output:

For the last test, I edited the alsa file again and commented out the default.pcm.dmix.rate line. Upon running miniaudio again with the same configuration, I got a lot of errors from miniaudio about missing a default rate, however it worked perfectly and the buffer size also reflects the period size of 480 (instead of the 1024, it was using previously). Here is the debug output:

I also tried changing the sample rate in miniaudio from 44.1kHz to 48kHz, and the audio card switched to that sample rate as well with no resampling.

I tried all these tests with the ((ma_snd_pcm_hw_params_set_rate_resample_proc)pDevice->pContext->alsa.snd_pcm_hw_params_set_rate_resample)(pPCM, pHWParams, 0); line commented out as well as uncommented as you suggested. This seemed to make no difference in the stuttering issues or resampling, or in the ability to set the sample rate on the audio card.

Anyway, thank you and hopefully this helps, and if you need more info let me know. I am happy to experiment in order to fix this problem.

[mackron]

Thanks. I'm somewhat surprised that commenting out set_rate_resample() makes no difference.

The errors you're getting in that last screenshot are definitely not coming from miniaudio directly. They're being fired from inside ALSA itself. I don't have an explanation for those ones.

I'll need to look into that resampling/stuttering/latency case. If the backend is reporting the same feature set I would expect it to work nicely regardless.