Audio output problems

[f4exb]

Audio output problems

[The-Fred]

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);

[f4exb]

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.

[The-Fred]

All I know is that the audio is working with that change. I suspect a problem in the Qt setup or Qt itself.

[The-Fred]

Since you mentioned sample rate I changed that code snippet I posted above

m_audioFormat.setSampleRate(rate);
to

m_audioFormat.setSampleRate(48000);

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.

[f4exb]

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.

[The-Fred]

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).

[The-Fred]

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.

[f4exb]

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.

[f4exb]

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.

[f4exb]

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.

[f4exb]

I don't know how I actually managed it but I succeeded following these steps:

• purged pulseaudio then reinstalled the Debian prerequisites mentioned in the main Readme including pulseaudio and libqt5multimedia5-plugins (these two are really missing from the dependencies of the sdrangel Debian package and should be added. Maybe that's the actual fix to this problem).
• very important but seems to concern the Udoo only: the HDMI output depends on the S/PDIF control and installing pulseaudio mutes it. I just used alsamixer to unmute it again.
• installed pavucontrol then selected HDMI from the profiles list in the 'Configuration' tab (maybe I missed that step in the first attempt)
• made sure that in the 'Output devices' tab of pavucontrol the HDMI / display port is selected (normally it's the only one)
• started SDRangel selecting 'alsa_output.pci-0000_00_1b.0.hdmi-stereo' for the audio output (default might work as well since pavucontrol has set HDMI as the default).

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).

[The-Fred]

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.

[f4exb]

In v.3.5.1:

• added pulseaudio and libqt5multimedia5-plugins in the Debian packages dependency
• added a paragraph in the Readme.md with details on pulseaudio setup