Issue 22

I am playing a radio station on a device which is running both, the Songcast Sender and Receiver. MPD is configured to output to a fifo (/tmp/mpdfifo). The Songcast Receiver is configured to output to ALSA:

Both MPD and mpd2sc audio formats are configured to 44100:16:2.

When using Songcast the quality of the audio stream contains much more static noise compared to playing the stream on the same device using aplay -f cd /tmp/mpdfifo.

Note, that no sample rate converter (NONE) is enabled in sc2mpd.

This is the log:

AFAIK, Songcast is a PCM sender and the receiver is passing the audio data as is to ALSA, right? Why mighty the output quality be reduced?

I really don’t know what may be happening. The NONE code is not well tested of course (I don’t think that the option is even documented).

Maybe you could have a look at the driver queue size with a change like the following: if it’s not reasonably stable (grows or shrinks), this might be an indication of the direction to look into.

----` diff --git a/sc2src/alsadirect.cpp b/sc2src/alsadirect.cpp index 4757f08..a339f77 100644 --- a/sc2src/alsadirect.cpp + b/sc2src/alsadirect.cpp @@ -727,6 +727,11 @@ static void *audioEater(void *cls) goto done; } } else { + static int64_t cnt; + if ((cnt %100)==0) { + int qs = alsaqueue.qsize() * tsk- >frames() + alsadelay(); + LOGDEB("QS: " << qs << endl); + } convert_to16le(tsk); }

----`

Testing on my intel pc, the queue grows very slowly (maybe 500 bytes/minute), so I guess that it’s going to cause problems at some point, but not right now…

So in my case the queue grows, until nothing works, because there is currently no code to discard buffers.

I run a test for about an hour on two Receivers:

 

For both Receivers, the queue size is slowly increasing: about 1000 bytes per hour.

This is a test audio file I recorded by writing the audio buffer to a file right after this line: https://github.com/medoc92/sc2mpd/blob/master/sc2src/sc2mpd.cpp#L348

[audio_test_file.zip](https://github.com/medoc92/sc2mpd/files/1085524/audio_test_file.zip)

When importing the file with Audacity (import as raw file) you can clearly hear the noises. Note, that the noise also occurs with SRC_LINEAR.

I also edited the Sender side to output the audio data to a file right after this line: https://github.com/medoc92/sc2mpd/blob/master/mpd2src/mpd2sc.cpp#L261

The noise is already on the Sender! I wonder why?

This sounds a little like it was converted to dithered 8bit at some point, I have no idea why.

I will investigate further tomorrow. Maybe you can point me to the function where the mpd fifo is read?

it’s in mpd2src/fiforeader.cpp, the function which actually reads is data()

Thanks!

It has something to do with swapping the audio data. The ALSA audio eater is configured with BO_HOST. As my device is Little Endian, swapping is activated in the Receiver here: https://github.com/medoc92/sc2mpd/blob/master/sc2src/sc2mpd.cpp#L340.

That’s why I activated also swapping in the Sender by running mpd2sc with -A 44100:16:2:1. However, this introduces the static noise.

For debugging of the fiforeader, I am writing the audio data before swapping and after swapping to separate files:

The audio file before the swapping is fine, whereas the audio file after the swapping contains the noise. So, there is something odd about swapSamples(). The parameters for swapSamples() are bytesPerSamp=2 and scount=882. This results in swab() being called, which is a system function.

Looking at the [implementation](https://git.musl-libc.org/cgit/musl/tree/src/string/swab.c) of swab() in musl shows that for swab(src, dest) the parameters src and dest should not be pointing to the same memory.

There is another question: If the audio file is already fine before the swapping, why do the swapping at all? If I hard-code needswap to false and disable the swapping in the Sender everything works fine.

EDIT: I guess swapping is required as the audio content of an AudioMessage is always PCM big endian encoded, as defined by the Songcast protocol.

Jörg Krause writes: > Thanks! > > It has something to do with swapping the audio data. The ALSA audio eater is > configured with BO_HOST. As my device is Little Endian, swapping is activated > in the Receiver here: https://github.com/medoc92/sc2mpd/blob/master/sc2src/ > sc2mpd.cpp#L340. > > That’s why I activated also swapping in the Sender by running mpd2sc with -A > 44100:16:2:1. However, this introduces the static noise. > > For debugging of the fiforeader, I am writing the audio data before swapping > and after swapping to separate files: > > write (g_fd_before, m_tmpbuf, size); > if (m_needswap) > swapSamples(m_tmpbuf, bytesPerSample(), m_tmpbufsize / bytesPerSample()); > write (g_fd_after, m_tmpbuf, size); > > The audio file before the swapping is fine, whereas the audio file after > the swapping contains the noise. So, there is something odd about > swapSamples(). The parameters for swapSamples() are bytesPerSamp=2 and > scount=882. This results in swab() being called, which is a system > function. > > Looking at the implementation of swab() in musl shows that for swab(src, > dest) the parameters src and dest should not be pointing to the same > memory.

That’s the bug, I guess that it ends up zeroing the low byte (the audio shows 8 bit quantization steps). It should be in the man page really !

I pushed a version which should swap in place allright.

Because Songcast data is always MSB first. Receivers expect it this way, there is no flag to say "this is LSB first".

jf

I can confirm that commit 5f89eacb14b05251c8d83795c642e7dbf108eaa0 fixes the issue.

Many thanks for the fixing this so fast!