search

xmos / sw_usb_audio

XMOS USB Audio reference design
Other
32 stars 16 forks source link

`AudioHwConfig` not getting called when switching between audio of different bit rates and sample rates #215

Closed mfreeborn closed 5 months ago

mfreeborn commented 5 months ago

Build config: 2AMi2o2xxxxxx, version 8.0.0, default xua_conf.h, Ubuntu 22.04, playing a selection of audio files using VLC.

I'm possibly misunderstanding something, but when playing 2-channel music on my PC through the multichannel audio evaluation board via USB, I would have expected AudioHwConfig to get called whenever I change to a track with a different sample rate/bit rate.

Adding a printf to the top of AudioHwConfig, I get the following, which all come in immediate succession the moment the application starts.

new audio config - samFreq 44100; mClk 22579200; dsdMode 0; sampleres 24
new audio config - samFreq 192000; mClk 24576000; dsdMode 0; sampleres 24
new audio config - samFreq 192000; mClk 24576000; dsdMode 0; sampleres 24
new audio config - samFreq 192000; mClk 24576000; dsdMode 0; sampleres 16
new audio config - samFreq 44100; mClk 22579200; dsdMode 0; sampleres 16

Subsequently playing a 192KHz 24-bit audio file, or indeed any other file, doesn't cause the function to be called again.

Using the secondary application PLL, I would've thought that I would need to switch between 44.1KHz-based and 48KHz-based master clock rates, or else I would get errors on playback.

All of the above said, audio seems to be playing fine, regardless of what quality I select.

(This issue might be better in lib_xua as most of the implementation details are there)

xross commented 5 months ago

AudioHwConfig() will absolutely get called every time the host sets the sample rate of the device. If the host ins't doing this it could be employing some SRC or similar. A USB bus trace would confirm this for you, but im very confident the device is doing the correct thing - we have many tests and multiple devices in the field.

mfreeborn commented 5 months ago

Thanks for the reply - you prompted me to look closer at my settings in VLC and I see that pulse audio was doing all sorts of unwanted pre-processing by default.

In the interest of answering this question for people coming across this in the future, I switched to Strawberry media player and selected the ALSA backend using the "hw" plug in. Now, I can see that the host is actively choosing the appropriate alternative interfaces (24-bit PCM vs 16-bit PCM in my implementation), along with correctly updating the sample rate depending on which file I'm playing.

On Thu, 11 Apr 2024 at 12:23, Ross Owen @.***> wrote:

AudioHwConfig() will absolutely get called every time the host sets the sample rate of the device. If the host ins't doing this it could be employing some SRC or similar. A USB bus trace would confirm this for you, but im very confident the device is doing the correct thing - we have many tests and multiple devices in the field.

— Reply to this email directly, view it on GitHub https://github.com/xmos/sw_usb_audio/issues/215#issuecomment-2049469033, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHSVKWHPBUPWEQA3EYTPB4TY4ZXETAVCNFSM6AAAAABFQXZ726VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBZGQ3DSMBTGM . You are receiving this because you authored the thread.Message ID: @.***>