-
Notifications
You must be signed in to change notification settings - Fork 447
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Audio output problems #31
Comments
This is only for demonstration purposes. It will need to be added correctly. But more importantly it would need testing on other hardware. Also I'm not clear why this works. diff --git a/sdrbase/audio/audiooutput.cpp b/sdrbase/audio/audiooutput.cpp
index 31698243b871..f31bdeaba212 100644
--- a/sdrbase/audio/audiooutput.cpp
+++ b/sdrbase/audio/audiooutput.cpp
@@ -91,8 +91,15 @@ bool AudioOutput::start(int device, int rate)
if (m_audioFormat.sampleSize() != 16)
{
- qWarning("AudioOutput::start: Audio device ( %s ) failed", qPrintable(devInfo.defaultOutputDevice().deviceName()));
- return false;
+ m_audioFormat.setSampleRate(rate);
+ m_audioFormat.setChannelCount(2);
+ m_audioFormat.setSampleSize(8);
+ m_audioFormat.setCodec("audio/pcm");
+ m_audioFormat.setByteOrder(QAudioFormat::LittleEndian);
+ m_audioFormat.setSampleType(QAudioFormat::UnSignedInt);
+
+ //qWarning("AudioOutput::start: Audio device ( %s ) failed", qPrintable(devInfo.defaultOutputDevice().deviceName()));
+ //return false;
}
m_audioOutput = new QAudioOutput(devInfo, m_audioFormat);
|
The problem is all parts of the software assume a S16_LE format for audio so I doubt it could work with a minimal change of code. However there is more flexibility on the sample rate. Normally most audio devices manage conversion in hardware so 48 kHz S16_LE is almost a standard. |
All I know is that the audio is working with that change. I suspect a problem in the Qt setup or Qt itself. |
Since you mentioned sample rate I changed that code snippet I posted above
And not only does audio still work but I don't see MCU warnings about "too long" and other MCU errors (which I can't recall now). I realize this is not very scientific or methodical approach but there does seem to be some strange code path involved here. |
I am very reluctant in applying these changes and I am wondering how a 8 bit unsigned format can work when the audio samples are formatted as 16 bit signed. The only thing that can be negotiable is the sample rate. It can even possibly be beneficial to use a larger sample rate if available if a relatively large bandwidth is used because it puts less pressure on the channelizer downsampling. |
Yes, wasn't meant to be a fix as I said, "demonstration", but without that code audio is broken here. Audio works fine for me in Audacity and ffplay (from ffmpeg). |
I have looked around and there is a project called CubicSDR https://github.com/cjcliffe/CubicSDR and I tried that and built it and sound is working well. |
Well I could reproduce the problem with the Udoo x86 board on Lubuntu 16.04 with the stock release 3.5.0 of SDRangel. In fact I have tweaked the .asoundrc file so that default audio goes to HDMI (plughw:0.3) because I don't have the 4 rings audio connector to use the (real) default audio device. The original code doesn't give much clues about what are the values in m_audioFormat. I will experiment with more verbose debug messages. |
While I was trying to prepare the machine to build SDRangel from sources I realized that pulseaudio was in the prerequisites. It is not in the Debian package prerequisites though and maybe this is really missing. It appears tp be missing libqt5multimedia5-plugins too. It appears to play an important role because when I tried the stock SDRangel just after that then I didn't get the error message anymore. I also had a much richer audio devices menu not only the default item. Yet no sound output on the HDMI though... I must say that I am not really aware of the ALSA and pulseaudio stuff. |
I've tried to make pulseaudio work with the HDMI output without success. It only really recognizes the primary real device hw:0,0 not plughw:0,3 which is the HDMI. A complete solution would be to get rid of that smelly pulseaudio and use RtAudio like CubicSDR but that's a huge amount of work. Until then SDRangel is only able to play on the main audio device. |
I don't know how I actually managed it but I succeeded following these steps:
All this might deserve a paragraph in the Readme. It is very straightforward with one sound device and one output in the system but gets very complicated if you want or have no other choice than selecting a different output. Also when the sound hardware doesn't run 48 kS/s S16_LE pulseaudio does the conversion so this guarantees that we can use this format in the software (not so smelly then...). Probably this is the reason why it spits out an error if this cannot be done and aborts the audio rendering (this part comes from the base code of sdrangelove I think). |
Yes, I had wondered why the debian control file had no mention of pulseaudio. I thought the build system might pull it in some other way. I don't run debian. I did include in the build pulseaudio but I wanted just plain Alsa. I never tried pavucontrol so I have to try that. RtAudio seems to be pretty good and is currently maintained and of course is portable to Mac/Win too. But as you see it is more work to change out the audio. I looked at what it would take quickly. Just a glance. |
In v.3.5.1:
|
I have built SDRangel from the "dev" branch and "master" and the problem I have with audio seems to be the same on both branches.
On startup I see these:
Then if I try different audio devices from the menu and then stop/start RX I eventually can get audio. And I see these:
The device I eventually selected is "default" . But I had to try all the different audio devices to finally get audio working.
I prefer to use ALSA for sound and as far as I can tell SDRangel should work with alsa or pulse. I did find a reference to a change between QT4 and QT5. In QT5 if pulse is found then it does not look for alsa. Debian patched around this behavior but I don't run debian.
Thoughts?
https://stackoverflow.com/questions/19985490/is-audio-playback-via-alsa-supported-in-qt5/27205912#27205912
The text was updated successfully, but these errors were encountered: