Alsa over HDMI goes async or gives crackling

[10robinho]

I've posted on forum about this bug: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=48769

After I talked to some gstreamer guys, it seams that this bug is related to alsa drives for Raspberry Pi.

Long story in short, changing "buffer-time" property of gstreamer alsasink makes sound late (if buffer-time is high) or makes crackling noise (if buffer-time is lower).

On other platforms, there is no need to change "buffer-time" property and there are no issues with gstreamer alsasink (this bug can be reproduced only with Raspberry).

Is there any chance someone can reproduce this, give an explanation or even fix?

[popcornmix]

The Pi has to send audio to the GPU, so and requires a larger buffer to avoid underrun than a processor that cam dma audio directly.

If the units for:
g_object_set(GST_OBJECT(alsasink), "buffer-time", 50000, NULL);
are microseconds, then it's quite possible that 50ms is the minimum buffer size that can be supported without risking underrun (and hence the crackles).

If this causes out of sync audio, then that sounds like a gstreamer bug, where it is not adjusting the audio/video delay by the audio buffer size.

[10robinho]

Yes, values are in microseconds. Default value is 200ms and there is no crackling when using it.

But, strange thing is that Raspberry is only platform that is having this desyncronisation with alsasink.

So, as far as I know now, several items are candidates for bug source: alsa drivers, alsa sink, egl sink or some internal Gstreamer.

I think that it is hardly possible that Gstreamer has internal problem as it is widely used and tested.

I'll try to see if I will get any feedback from people who are familiar with alsasink.

Anyways, it would be really pity that Gstreamer don't work properly on Raspberry.

[popcornmix]

I'm sure gstreamer has an option to specify the delay between video and audio.
You probably just need to set this to 200ms.

[10robinho]

That would be great if delay is really 200ms. But problem is that delay is 0ms on start (sync is working) and it is increasing proportional to number of play-pause events.

[popcornmix]

I don't think anything will be done about this without some evidence of where the problem is.
The crackles when buffer size is too low is expected behaviour.

Going out of sync could easily be a gstreamer problem.
If there is an alsa problem, you really need a small program that provokes the problem without gstreamer/egl etc.

[10robinho]

OK, I will report back when I debug Gstreamer more, to find out possible source of bug.

It would be great if anyone can try to compile samples I attached on bug report and to confirm this.

Here is bug report https://bugzilla.gnome.org/show_bug.cgi?id=703330

[10robinho]

I've found exactly the same problem with mplayer using alsa sink.

There are steps how to reproduce it easily:

1. Here is video I used http://goo.gl/W4p6v. Note that is super-small because I had to make sure Raspberry can properly reproduce it without any GPU help. But still, it is h264 + AAC in mp4 format. I used ffmpeg to reduce original Simpsons movie trailer that can be found here http://goo.gl/HXXvX.
   I find it good for testing audio because Homer slaps those wolfs in start and it is easy to see is audio is synced :)
2. Install mplayer :) I used Arch packages
3. Start X
4. Run: mplayer -va x11 -ao alsa video.mp4
5. Hit space couple of times until you realize that sound is late

It would be great if someone could confirm this bug.

[10robinho]

@popcornmix have you tried to reproduce this bug?

Is there anything I can do to help fixing this?

[julianscheel]

We're just stumbling into the same/similiar issue with our VLC implementation. Actually from our current understanding it looks as if snd_pcm_drop is not behaving correctly. Whenever VLC thinks that audio is way too late and tries to flush the audio output, the audio delay compared to video grows.
Analysing this we are currently thinking about the workqueue implementation of the snd_bcm2835 driver.
@popcornmix Could it be that the workqueue behaves as an in fact unlimited buffer, because snd_pcm_write calls are pushed to the workqueue asynchronously from actual tranfer to videocore? And then if a stop with snd_pcm_drop is executed this is just pushed onto the same workqueue, so it will only get executed after all previous write calls have been finished?
We are trying to find an easy test-case for this...

[dennis-hamester]

MPD is also affected by issues regarding snd_pcm_drop and they implemented a workaround. See this commit.

[10robinho]

Check
https://github.com/albertd/buildroot-rpi/commit/b56624dcd4237f9a67231dd225884e372d4917e3

[dennis-hamester]

Great, thanks! We will try that patch

[10robinho]

@dennishamester we tried to adopt that patch to Kernel from github.com/raspberrypi/ and we have found out that it works only for Kernel 3.9 and that it resets alsa settings after call (ei. that means sound jumps on 100% every time).

It would be nice to have fix for this, now when root of problem is known.

[popcornmix]

@julianscheel a simple test case of the problem would be very helpful.

Assuming the problem described is fixed by the kernel patch, it looks like a stop message with alsa_stream->draining==0 is the problem case. Agreed?

There is a queue of audio data on GPU side. Is the desired behaviour for that queue to be flushed when a stop message comes through with alsa_stream->draining==0 ?
I assume I report the samples have been played (just taking no time), so dma read_ptr==write_ptr after this?

[dennis-hamester]

@popcornmix yes, the problem appears when stop messages with draining==0 are generated. These come from snd_pcm_drop, which expects playback to stop immediately, with all pending buffers being discarded.

[popcornmix]

@dennishamester
I'll try implementing that, but it would be useful if someone could provide a script that provokes the failure, and explain what the desired behaviour is.
The simpler the test, the better.

[dennis-hamester]

We're working on it

@10robinho The patch seems to work for us. Thanks again

[dennis-hamester]

Here's a tool to debug this issue:
Source: https://gist.github.com/dennishamester/7600799
Binary: https://dl.dropboxusercontent.com/u/52834708/alsa-playback

The tool queues sound for 1 second, then drops. this cycle is repeated 10 times. On my host machine, I hear nothing, a slight crack at most. On the rpi, there is audio output for several seconds.

Might be useful:
The issue did not trigger when queuing much less than 1 second, like e.g. 250ms. I believe the alsa buffer (~300ms for this tool) must be exceeded to actually see the problem.

[popcornmix]

@dennishamester
How are you running alsa-playback?

/alsa-playback default
rate: 48000 -- frequency: 750.000000
cannot set parameters (Invalid argument)

[dennis-hamester]

@popcornmix
Try with hw:0. I'm looking into this

[popcornmix]

Can you try this build:
https://dl.dropboxusercontent.com/u/3669512/temp/start.elf

Note: this is test build with a fixed 256M/256M gpu/arm memory split.

It should drop queued audio data when requested.

I don't know if I agree that there shouldn't be any audio played while data is being submitted.
As the alsa driver is handled by a separate processor with queued messages, then it takes some time for those messages to arrive during which time we are suposed to be outputting audio.
Just because a different alsa card with a local dma buffer is able to fill and halt its buffer almost instantly doesn't mean that's the correct behaviour.

I would agree that no samples should be output after the final:

snd_pcm_drop(playback_handle);

but I'm not sure if they were before my update.

[10robinho]

I've tested new start.elf and it is good in 95% of time.

In other 5% I hear strange noise, like crackling. I've recorded it with phone, you can get it here http://goo.gl/j6AlhC

[popcornmix]

@10robinho
is the recorded noise something new?
is the updated start.elf preferable to default one?
What can I do to reproduce the noise you heard? hdmi or analogue output?
Do you hear noise from aplay?

[julianscheel]

I will try to test the new image tomorrow, but it might be that I can make it on wednesday only. Will let you know the results with VLC then.

[10robinho]

@popcornmix

is the recorded noise something new?

No, but before your fix, it was much much more ofter, like 8/10 times.

is the updated start.elf preferable to default one?

Yes, I just replaced them.

What can I do to reproduce the noise you heard?

I've used Gstreamer program and paused->play->pause->play-> ... video from disk.

I believe same thing can be see with VLC, but I haven't tried.

hdmi or analogue output?

HDMI

Do you hear noise from aplay?

I didn't test it much, as I don't know how can I reproduce it with aplay.

Now, I will try to reproduce it with dennishamester's program and report if I managed to do it.

BTW, sorry for closing and reopening issue, I'm clumsy :)

[julianscheel]

@10robinho Before you spend too much time with the test program: We are not very sure that this is a good testcase anymore...

[popcornmix]

The drain fix from the test build is now in latest rpi-update firmware.

Is there still a problem, and is there a test case to show the problem?

[giszo]

I am developing my own audio player application for the Raspberry Pi and I faced the exact same problem that is described in this issue. Doing a lot of play-pause-play-pause-... operations sometimes cause periodic crackling in the audio output.

My pause implementation simply calls snd_pcm_drop() on the ALSA handle to drop everything from the output buffer to stop playing. Removing the snd_pcm_drop() call from my sources fixes the problem perfectly.

One more addition to the report is that I have the same problem on the analog output of the Pi as well.

I am using a recent Pi firmware but if you need more information about it feel free to ask me.

[popcornmix]

@giszo
If you can produce a simple test program that clearly does something wrong, then I'd like to see it.

[giszo]

It took a little bit of time but I was able to reproduce the issue with the following application: http://minimaldiff.hu/zeppelin/test.c
Be warned that the source of the given test application is just a quickly hacked application. :)
The interesting parts:

• init_alsa() function -> ALSA library initialization
• handle_input function() line 155 & 157 -> playback is stopped here
• main() function line 192 & 215 -> decoded audio is played here.

You will need libmpg123 to be able to compile the application with something like this: "gcc -O2 -lasound -lmpg123 test.c -o test"
An mp3 file with 44100Hz sampling rate and 2 channels is also needed. To start the application simply do "./test your_music.mp3"

By pressing space multiple times the tester will start and stop playing of the specified file. Escape can be used to quit from the application.
My test scenario is something like this:

• press space -> playback starts
• wait a few (~3-5 seconds) -> make sure played audio is fine
• press space -> playback pauses
• wait a sec
• repeat from the beginning ...

Sometimes the issue pops up right after the second try, sometimes it requires a lot of pressing on space, but I can reproduce it aytime on my Pi. When I hear the periodic glitches in the audio its period is somewhere between 500ms and 1s.

Let me know if you need further assistance.

[popcornmix]

@giszo
I could compile your code, and after a few pause/unpause cycles I got the glitches.
I'll look into it.

[giszo]

One more observation I did yesterday that may help, but I am not totally sure about it: if I moved the snd_pcm_prepare() call to be executed only when playback is started, the problem didn't show up ... or I was not trying it hard enough. :)

So I would think that the problem is caused by calling snd_pcm_drop() and snd_pcm_prepare() right after each other.

[giszo]

@popcornmix did you have time to look into this issue?

[popcornmix]

I've been looking at this for the last few hours, and not getting very far.
The samples always look plausible all the way through the chain.
If you send silence rather than music the noise doesn't seem to occur (although as the test is intermittent, I've frequently been drawing incorrect conclusions).
I'd deciding the reporting of how many samples were consumed was probably causing the problem, and calculating them different ways seemed to help, but it was just chance...

I've finally found a smoking gun. Just before the noise I get a buffer with an odd number of bytes. That's pretty surprising - I'd assume that alsa deals in 2 bytes per sample and 2 channels, so I'd always see multiples of 4. I think after the odd byte buffer, we play that buffer endian reversed causing the noise. The next buffer is off too, which flips it back causing the noise/good cycles.

It's too late now, but I've got something concrete to debug in the next day or so, so hopefully will have a fix soon.

[giszo]

It is nice to hear that there is some promising progress. :)

[popcornmix]

I've got a test build for you to try:
https://dl.dropboxusercontent.com/u/3669512/temp/start_alsa.elf

This has a fixed memory split of 128M/128M.

Can you test if it seems okay, and if so I'll make a new official firmware.

[giszo]

The link does not seem to work as I get 404.

[popcornmix]

Sorry, should be there now.

[giszo]

Tested it and the problem is fixed as far as I can tell.

[popcornmix]

rpi-update firmware should now have this fix.
@10robinho Does this help your issue?

[popcornmix]

Any reamaining issue here or is it okay to close?

[giszo]

For me it is fine to close the issue.

[julianscheel]

From our side it can be closed.

[10robinho]

I'm sorry not to respond earlier.
Looks like problem is solved, I'm closing the issue.
Thanks @popcornmix :)