Closed jpuigs closed 5 months ago
Setting SB settings to 96 KHz. instead of 48 KHz., works much better, but still some drops....
No, I cannot confirm it.
23:31:43.395 [I] AudioDecoder: HE-AAC 32 kHz mono
23:31:43.396 [I] AudioDecoder: Output sample rate 32000 Hz, channels: 2
23:31:43.746 [W] SPIApp: DNS lookup failed: "0.9440.9200.9e4.dab.radiodns.org"
23:31:43.809 [I] AudioOutput: Unmuting audio
I only have one 32 kHz program (in mono), but there are no dropouts.
I also have only 32kHz mono service, could you please share the recording? What is your operating system? Do you use prebuild binaries or have you built from source?
Analysis of the problem:
The dropouts are probably caused by decoding errors because the log says: AudioDecoder: Muting audio (decoding errors)
What is a quality of the signal you are receiving (SNR)?
There is probably an additional problem with output device because something has changed when you changed sampling rate. Application does not do any sampling rate conversion and fully relies on audio framework. If you use prebuilt binaries and did not change defaults, PortAudio is used (by the way, this information should be at the beginning of the log and I do not see it in the log you have shared). You can try for switch to Qt audio framework to make it running @ 48kHz: https://github.com/KejPi/AbracaDABra#expert-settings
I guess you won't have audio problems when you save the content to a file...
I was using windows version 2.2.3 (windows 10 pro 64b), and I upgraded to 2.3.3, but results were the same ones. signal quality is 15-16 dB. Since changing sundblaster output to 96 KHz (which is 3 x 32 KHz), it works fine.... only one error in 10 minutes.....
Here you have 2 minutes recording (470 MB): https://we.tl/t-dwrqb7cJt0
I'll try qtaudio, thanks.
Thank you for the recording, much appreciated. Was the error happening also during this recoding? If yes, the what service did you listen to? I am playing the file on Windows using bluetooth headphones and it works without any problem, there are also no decoding errors, so there should not be any audio dropouts.
What do you see in the log when you hear the dropout? I would still recommend to try with Qt Audio framework and 48kHz output rate. It might work better with SoundBlaster.
And by the way - according to encemble label I would say it is a testing ensemble from Barcelona, am I right? But the country ID is set to France.
During this recording was NO dropouts. When I hear dropouts, it appears what you saw in first post.
Later I'll try qtaudio. Yes, yes, you're right, it's from Barcelona and the country ID is wrong !!!
I've noticed that RTL_TCP doesn't start automatically on v. 2.3.2 and 2.3.3. using manual option in settings. Device and software options work fine. I have to manually change gain value +1/-1 to wake it up ! , but I close program and when opening again, and it's 0 dB. On version 2.2.3 worked fine.
I've tried qtaudio output, and results are the same ones.... Using SB output at 48 KHz. wrong, and at 96 KHz. right.
Now, I see it's not AbracaDABra problem, because I've tried using other software like DAB Player, and it happens too with those 32 KHz. services. I hadn't noticed it because here we had no 32 KHz. sampled stations, we have them since a few days ago, and everything played correctly before on 48 KHz. ones.
It seems that SB does not support 32kHz input - just theory. I will check RTL_TCP manual gain settings, thanks for reporting.
If the log says the same as in the first post, it is due to decoding errors - this could be caused by reception distortions but even by errors in brodcasting. I have one service here that also has these problems while other services in the ensemble play fine and there are no FIB errors. You can check in other tool if you have these dropouts too.
If the log says the same as in the first post, it is due to decoding errors
Yes, same messages.
On radio devices like Technisat Viola 2, and on car receiver, there is no problem with those 32 KHz. services. So I guess it's SB problem.
Later I'll comment a little bug in ensemble information in another post.
Audio decoding problem (log on top) has nothing to do with audio device. It would be interesting to see what is really happening during the dropout.
I can add some info. When SB is set to 48 KHz. and problems start, it seems audio is still in input buffer, because I close program, and I have still audio during several seconds. I'll try to do a video later.
@jpuigs I have created issue #107 for RTL_TCP problem, please comment there
I can not hear correctly one MUX in which all stations are sampled at 32 KHz.
Log says: