The 32k sample rate I use is simply because that is what the rtl_fm program uses. I had no stutter or strange audio artefacts, of course it is FM radio audio quality, same as for old radio in car for example.
I do not know the device you are using, also do not know your pulse-audio version and setup. I use a PI4B (quite heavy loaded server) 3.5mm output audio to a mini stereo amplifier/speaker. I use pulse-audio clients on rolling Linux distro via the network capbility of pulse-audio. That works very well, only issue with older Debian on some Pi clone board, was a timing/sync issue, no issue now anymore with 6.6 kernel.
So from SW technoligy point of view, pulse-audio must be able to handle things. You might have mutiple instances running or so, I don't know. I use strickly user-only, no root.
If the samplerate and/or datarate fom your device is not exactly as you specify (48k) or has jitter, it is no surprise you experience stutter. It is only a unsync UNIX pipe between nc and play. So maybe have a look at that. Maybe there is some real-time 'spike' issue w.r.t. the device.
I do not know the device you are using, also do not know your pulse-audio version and setup. I use a PI4B (quite heavy loaded server) 3.5mm output audio to a mini stereo amplifier/speaker. I use pulse-audio clients on rolling Linux distro via the network capbility of pulse-audio. That works very well, only issue with older Debian on some Pi clone board, was a timing/sync issue, no issue now anymore with 6.6 kernel.
So from SW technoligy point of view, pulse-audio must be able to handle things. You might have mutiple instances running or so, I don't know. I use strickly user-only, no root.
If the samplerate and/or datarate fom your device is not exactly as you specify (48k) or has jitter, it is no surprise you experience stutter. It is only a unsync UNIX pipe between nc and play. So maybe have a look at that. Maybe there is some real-time 'spike' issue w.r.t. the device.
Statistics: Posted by redvli — Sun Aug 11, 2024 1:23 pm