You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is a very excellent project. -- We use it successful at our radio club station with a Raspi5 and an IC7300.
But when I wanted to transfer the Software to an other station with a Debian12 8-core-amd-x64 - machine connected via soundcard (internal and USB- CM108) to a FT847, I have some problems with the audio stream, even on localhost bowser, which shows that it seems independent from the network delay.
I use the newest pyaudio in venv and I activate the executing python3.11 for the UHRR from venv.
The problem is: the stream is stuttering with several times per second. (as shown in the included figure)
I checked to changed some parameters in the program but does not give success.
All my experiments, I get interrupted audio stream, even on the localhost connection.
A popup shows "Problem". On the server console, I notice several "overun" messages from the recording loop.
With the original code only one short audio (about 100 ms) is transferred at the program start.
with my changed code, the stuttering happens -- Let me call it an improvement... ;-)
Now I am without any idea where to look deeper in.
on the server, I used a dsnoop:CARD=..... as well as a plughw:CARD=.... since the audio sample rate conversion is needed.
I made some experiments in the source code
One experiment was to change the sampling to FORMAT_S16_LE. Than I have to catch the buffer contents into numpy array float32, divide it and convert it with to_bytes back to a floating point bytestream -- this gives some improvements, but does not solve the "interrupted stream"
with some debugging, I found out, that the PCM-Buffer consists of 8192 bytes while the length of chunks is reported to 1024 chunks independent to the selected periodsize (32, 64, 96, 128) of the initial declaration of the stream.
So let me ask, if anyone has an idea, what to change in code or system configuration...
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
It is a very excellent project. -- We use it successful at our radio club station with a Raspi5 and an IC7300.
But when I wanted to transfer the Software to an other station with a Debian12 8-core-amd-x64 - machine connected via soundcard (internal and USB- CM108) to a FT847, I have some problems with the audio stream, even on localhost bowser, which shows that it seems independent from the network delay.
I use the newest pyaudio in venv and I activate the executing python3.11 for the UHRR from venv.
The problem is: the stream is stuttering with several times per second. (as shown in the included figure)
I checked to changed some parameters in the program but does not give success.
All my experiments, I get interrupted audio stream, even on the localhost connection.
A popup shows "Problem". On the server console, I notice several "overun" messages from the recording loop.
With the original code only one short audio (about 100 ms) is transferred at the program start.
with my changed code, the stuttering happens -- Let me call it an improvement... ;-)
Now I am without any idea where to look deeper in.
on the server, I used a dsnoop:CARD=..... as well as a plughw:CARD=.... since the audio sample rate conversion is needed.
I made some experiments in the source code
One experiment was to change the sampling to FORMAT_S16_LE. Than I have to catch the buffer contents into numpy array float32, divide it and convert it with to_bytes back to a floating point bytestream -- this gives some improvements, but does not solve the "interrupted stream"
with some debugging, I found out, that the PCM-Buffer consists of 8192 bytes while the length of chunks is reported to 1024 chunks independent to the selected periodsize (32, 64, 96, 128) of the initial declaration of the stream.
So let me ask, if anyone has an idea, what to change in code or system configuration...
Thanks in advance
Michael
Beta Was this translation helpful? Give feedback.
All reactions