Sporadic audio output issues ... #334
Labels
Comments
|
If you record the I/Q stream with If you redirect audio output to a WAV file with |
Additional InformationI was looking at the RTL-DSR Wiki and found hdfm. Figured I'd give it a try. Got it installed and ran it: It worked on my local channel 104.1 and I got audio output! But I want channel 2, so I killed it and restarted it: And got the dreaded blip followed by no audio. It took 6 stop/starts before I got continuous audio on 104.1 2 (it's playing as I type this). Why I'm adding dataThe hdfm UI shows HDFM at the top left, the date and time top right. Below it puts album art on the left with channel data on the right:
As I waited for the D/A decoding to happen, I saw a zero 0 put in the Title: field, then in the Artist: field, then all the fields got populated with information. That's when the blip sounded! And no subsequent audio output. It seems that there is a transition point in the signal processing where enough data is processed to populate the information display followed by audio output. That's when it horks. I'll gather the requested audio files and report back. |
|
Interesting. I have an iq file with the blip: https://www.dropbox.com/scl/fi/9nkp6fg2dnp36j4sfouvn/iq.out.zip?rlkey=63kbm2nr1rpww904ygnmvs5ul&dl=0 Cannot upload directly as it's 35Mb. Interestingly I did the audio file output, piped into aplay, and it works. In fact, it seems to work everytime! I did a toggle this way: So, it seems that it's the onboard audio processing in nrsc5, as it fails with nrsc5 at a terminal, in hdfm (started from a terminal), and nrsc5-dui (both of these applications use nrsc5 as their backend processor) yet output of WAV piped into aplay works immediately after nrsc5 does not. |
|
Strange, I haven't encountered that problem before. The main audio playback loop is here: Lines 800 to 830 in 80ab64e Perhaps you could add a |
Produces no output visible on screen when the blip occurs. But does get shown when the audio output is successful: |
|
Sorry I took so long to reply - I was looking for command line audio players I can use that provide controls in a gui, etc. rather than just route audio to ALSA like aplay, mpv, play, etc. Turns out audacious works. GUI pops up and I can change the volume in it. Can't do much else, but that's fine for now. |
|
Interesting. Perhaps you could add some further logging, in particular around the It's possible there could be a race condition somewhere. |
|
P.S. I LOVE that we're using printf() to do debugging. My god! LOL Takes me WAAAAAY back to when I learned to code C on a DEC VAX system at Stetson University in 1985. |
Output: |
|
NM about adding time stamp. I see I can use the log_info() function for that. |
|
From your log, it seems like maybe the audio thread is getting stuck trying to lock the mutex. Could you add unique log messages before and after each of the two |
|
In the while() loop: Also enabled the other two DEBUG lines you've asked for. Log is attached. the first pthread_mutex_lock is logged, but not the second one. There is one ao_play, with, as before, interspersed pthread_cond_waits. I should mention that this is an MXLinux box and it does not use SystemD. PulseAudio is running. |
|
Do you still have a debug line after the |
|
Also, could you post the contents of |
|
I booted up MX Linux in a VM, and I see that |
|
Sorry I didn't respond yesterday. I did not have the DEBUG line after ao_play. I have put it there for a new run. With the change to the /etc/libao.conf file, the blip does not occur in sequenced testing. Yesterday I had to run nrsc5 maybe six times before I got sound past the blip. Today with that change five successive runs and no blip. I appreciate you going to the trouble to spin up a VM for MX Linux. I'd have never thought to look at any file in /etc/. I'll use it today and report back. |
|
Thanks for the update. It seems like libao's ALSA driver is a likely culprit. Here's a similar case that another project ran into: PromyLOPh/pianobar#623 I haven't encountered the issue because Ubuntu switched the default driver to Pulse, but the upstream Debian package still defaults to ALSA. Perhaps this is another good reason to switch from libao to PortAudio, as was previously contemplated in #265 (comment). The only downside is that PortAudio doesn't have any built-in support for writing WAV files, so we'd either need to roll or own or use something like libsndfile (which would have the benefit of supporting other output formats). |
|
Perhaps a comment in the README.md file that specifically mentions checking the conf file to confirm it's set to pulse. Or a modification to the "make install" to put in place, or modify, the conf file. That is a fairly trivial change for users to make (and certainly easier than writing code -- well for me to write that code). |
|
Now to get nrsc5-dui's GUI to stop failing (interestingly, the nrsc5 process it spawns continues to work, and play music, but the GUI simply goes away). |
That's not good... Raise an issue over there with whatever pertinent info you can provide and I'll take a look into it. |
|
Of course, right now it's working just fine, though I did start it differently - at a prompt specifying frequency and channel. |
|
Windows 10 version |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Linux HOLLIN 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-2 (2023-07-27) x86_64 GNU/Linux
MX Linux MX-23.1, KDE Plasma 5.27.5, Debian 12.2
nrsc5 revision 80ab64e, RTL-SDR v3 receiver, using the dipole attenna.
Short Story
Sometimes nrsc5 runs, appears to connect to the RTL-SDR dongle, and start playing the streams, only to have the audio stop playing.
Long Story
I Run nrsc5 at a terminal prompt:
What I hear is a small blip, chirp, 5-10 seconds in, and then nothing. This happens both running nrsc5 from a terminal prompt and from within nrsc5-dui.
I run with logging enabled:
This is random across all of the six HD stations, and their subchannels, in Madison WI where I live.
It cannot be the RTL-SDR v3 dongle. Even when ncrs5(-dui) are having this "issue", I can run SDR++ and it works with audio output.
The audio configuration for my Linux box clearly shows that nrsc5 is connected to ALSA as along as I keep it running (without q or Ctrl-C). While running, changing channels (1, 2, 0) has no affect on the audio though I can clearly see the channel change (because Titles change if I have debug enabled). The debug output looks identical whether the audio is sounding or not sounding excepting channel information.
When it works, it's brilliant. Listened for three hours today to a subchannel I had no idea existed (Great American Songbook, Sinatra, etc.). When it doesn't work it's maddening.
I have ...
The text was updated successfully, but these errors were encountered: