What card is it?My soundcard? I'm simply using my laptop's integrated sound card (ALSA calls it "CX8070 analog").
Conversion from 9.6kHz to 48kHz should be pretty straight forward, depending of how good results you want. The ratio of 48kHz / 9.6kHz = 5, which is a nice integer value. A brute-force method would be using just a simple linear interpolation, but the result may not be as good as you might want.
audio_source |sox -r 44100 -t raw -e signed -b 16 -c 1 - -r 44100 -t raw -e float -b 32 -c 1 - |audio_consumerand I'm running this on a Ryzen 5 3500UI'm resampling with linear interpolation from 48 kS/s stereo 16 bit to 1.536 MS/s stereo 16 bit (32 ×).
I'm beginning to think that my problem here is that my code needs to convert short "bursts" of data (whatever number of samples the modem_process is spitting out) and then sit idle until the next block of data comes, so my soundcard just runs out of samples before the new block of data is generated and converted. It's more of a latency problem than an issue with speed per se, if that makes sense.Quoteand I'm running this on a Ryzen 5 3500UI'm resampling with linear interpolation from 48 kS/s stereo 16 bit to 1.536 MS/s stereo 16 bit (32 ×).
In real time. On a Raspberry Pi Pico.
And on a RPi3 I'm using Python and scypy resampler lib to resample, still in real time, from 12 kHz to 48 kHz - float stereo to 16 bit stereo.
Definitely something else is amiss, for an R5 3500 this should be load background noise in terms of loading.
Part of the problem is that the modem_process function doesn't always return a full 2048 samples (output data size can vary quite a bit depending on what the code is doing) and I obviously have to wait for it to finish processing before I can write or read new data.
Yeah, but if the modem_process code works on "sound" hardware that supports 9.6 kHz sample rate, and does so on slow processors, it should be more than capable of pushing enough data to keep the soundcard buffer full while it generates newer data, right? I ran another test, and the resampling code does work if the size of the data generated by modem_process is less that a couple hundred samples, so I would say that it's my resampling code that's too slow. I used libsamplerate with the "SRC_ZERO_ORDER_HOLD" mode, which according to the documentation should be "blazingly fast"...
Uh. Is that not just "part" of the problem, but your whole problem precisely?
Aren't there some ALSA plugins which can convert sample rate on the fly, so that you can send PCM data at (say) 8kSa/s while the sound card still runs at (say) 48kSa/s?I tried plughw, but it does not support snd_pcm_link, so the code does not run
[ This still does not solve any synchronization/flow-control problems, of course - they are a different issue. ]