Hi, 

I have tried to reproduce your issue without success. Maybe because of a different platform.

would suggest:

1/ Check, if you can reproduce it with latest version of SDL2 and latest version of SDL2_mixer

2/ Can you reproduce it on PC ? (32 bits or 64 bits ?)

3/ if you want to test you assumption, maybe you can increase frequency/channels :
x4 the frequency up to 176400
x3 the channels up to 6.

This should divide the time by 12, and that would happens after 33 minutes.

4/ if this still happens, you could re-create a new test-case based only on SDL2 (see SDL_audio.h). That would tell whether the bug is in SDL2 or in SDL2_mixer.

Hi Sylvain, 

First of all, thank you for your answer.
It take me a while but here the answer : 

1) here the version used for the last test : 
* sdl c2ef0d8d6da0 revision 9255
* sdl-mixer b28b41b93ba7 revision 697

configuration sdl : 
configure --build=x86_64-linux --host=arm-oe-linux-gnueabi --target=arm-oe-linux-gnueabi --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib/libsdl2 --datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib --includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent -rules --disable-dependency-tracking --with-libtool-sysroot=/home/kapt/Linux/sources/poky/build/tmp-eglibc/sysroots/q7imx6kpack --disable-oss --disable-esd --disable-arts --disable-diskaudio --disable-nas --disable-esd-shared --disable-esdtest --disable-video-dummy --enable-input-tslib --enable-pthreads --enable-video-directfb --disable-video-opengl --disable-video-x11 --enable-sdl-dlopen --disable-rpath --disable-pulseaudio --enable-alsa --disable-alsatest

results : still got the same error

2) No I can not, I tried to launch application with linux32 ./soundTestSansQt but nothing happens, even after 10 hours. The programme had been tested on Ubuntu (with config by default).
I just installed an ubuntu 32b on a computer, waiting for the results.

3) I create a new 176400 Hz sound with audacity, change the frequency Mix_OpenAudio(freq) and exec the programme.
The sound isn't crackling anymore but after 3h21 +/- 4minutes they is no sound at all.
88200 Hz no sound at all after 6h45.
I do not understand how number of channel can impact the bug. I mean, channel is not for mono nor stereo but for different sound sources doesn't it?

4) Need a moment to test it.

Best regards.

Hi, 

About the channels number, you are probably right.
I am not sure whether channels should have an impact on your issue or not. Just a guess to check if the given formula is correct (but maybe 2 channels is the maximum). The idea was to make the problem easier to reproduce.

Instead of 4/ you could also to try to run it with "valgrind". It would probably point out some invalid read/write access. (maybe the SDL & SDL_mixer need to be compile with -g -O0).

Ok, 
Here some news : 

2) I installed an ubuntu 32b on a computer and started the test : 
Every thing is normal since yesterday 10h50 am (no bug).

4) New program with SDL2 only (SDL_LoadWAV, SDL_OpenAudio, SDL_PauseAudio, SDL_MixAudio ...) on arm.
Parameters 176400Hz
The bug appear after 3h25 with the following error message : 
"ALSA write failed (unrecoverable): Unknown error"
At least we can say it is not SDL_mixer.

5) trying with -O0 result in 3 hours.

That reduce the scope! The issue could be in the alsa back-end as the error message says.


We could give another tryon linux 32 bits: Pulse Audio is used by default, we could switch to ALSA.

http://howto.blbosti.com/2010/04/ubuntu-make-alsa-default-instead-of-pulseaudio/
https://wiki.ubuntu.com/Audio/Alsamixer

I am not sure of the steps to setup ALSA correctly.
(Maybe ALSA just needs to be enabled when compiling SDL, and pulse audio disabled)



By the way:

ALSA audio is in "src/audio/alsa/SDL_alsa_audio.c"
There is the error message:

   321 fprintf(stderr, "ALSA write failed (unrecoverable): %s\n",

https://hg.libsdl.org/SDL/file/6fe4583d7e1f/src/audio/alsa/SDL_alsa_audio.c

(A few printf there, would make sure we run ALSA on ubuntu)

ALSA can be enabled by setting the following environment variables before running your application:

 export SDL_AUDIO_ALSA_DEBUG=1
 export SDL_AUDIODRIVER=alsa

So, very easy to run it on linux 32bits.



Moreover, I have seen with "valgrind" that your app is doing an invalid read:

 const char *file = (std::string("Sounds/") + std::string("bip90.wav")).c_str();
 _sonBip = Mix_LoadWAV(file);

can be quickly solved with:

 char *file = strdup(std::string("Sounds/") + std::string("bip90.wav")).c_str());
 _sonBip = Mix_LoadWAV(file);

It is worth retrying with this fix also.

Created attachment 1965 [details]
0001-ajout-printf-debug.patch

add some printf in src/audio/alsa/SDL_alsa_audio.c

I add some printf with 0001-ajout-printf-debug.patch (see attachments)

and got the error : 

ALSA write failed status: -1073741824
ALSA write failed status2: -1073741824
ALSA write failed frames_left: 4096
ALSA write failed (unrecoverable): Unknown error

Some ALSA documentation:

http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#ga2157aaeb6fc14da3f040d76591f9d3b1

http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#gabc748a500743713eafa960c7d104ca6f


The error code "-1073741824" is not one of -EINTR, -EPIPE, -ESTRPIPE, -EAGAIN.
So "snd_pcm_recover" does not handle anything.

This error code comes from the "snd_pcm_writei" function. But it's neither a known error code from the function.

So, it could also be somewhere else. Could be the memory issue from my previous message.

Here are the error codes:
 -EINTR = -4    
 -EPIPE = -32
 -ESTRPIPE = -86 
 -EAGAIN = -11 
 -EIO = -5 
 -EBADFD = -77 
  1073741824 = 0x40000000  (1073741824>>28) == 4 



1/ Fix the valgrind issue from my previous message. And make sure you still have the problem on your board.

2/ Try to run it on Linux 32 bits, with ALSA enabled to see what happen.
  
3/ If you can on your board, run it with valgrind. 

4/ Upgrade ALSA ...

5/ Look from kernel/system message log 

6/ You can also give a try without SDL:

Here's a very small program that you can transform into an infinite loop.

http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_min_8c-example.html#a6

or:
http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html#a30

Morning Sylvain,

1) fix the valgrind issue : nothing change, bug still appears after 3.25hours

2) bug appears with 32b ubuntu and export SDL_AUDIO_ALSA_DEBUG=1 export SDL_AUDIODRIVER=alsa

good job.

3) Here the result with valgrind : 
ALSA status value: 4096
ALSA status value: 4096
ALSA status value: 4096
ALSA status value: 4096
ALSA status value: 4096
ALSA status value: 4096
ALSA status value: 4096
ALSA status value: 4096
ALSA status value: -1073741824
ALSA write failed (unrecoverable): Unknown error
SDL_PauseAudio Fri Dec 12 14:51:05 2014

^C==1769== 
==1769== HEAP SUMMARY:
==1769==     in use at exit: 145,489 bytes in 1,777 blocks
==1769==   total heap usage: 2,603 allocs, 826 frees, 189,449 bytes allocated
==1769== 
==1769== LEAK SUMMARY:
==1769==    definitely lost: 0 bytes in 0 blocks
==1769==    indirectly lost: 0 bytes in 0 blocks
==1769==      possibly lost: 35,204 bytes in 1,709 blocks
==1769==    still reachable: 110,285 bytes in 68 blocks
==1769==         suppressed: 0 bytes in 0 blocks
==1769== Rerun with --leak-check=full to see details of leaked memory
==1769== 
==1769== For counts of detected and suppressed errors, rerun with: -v
==1769== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Does not look like any error appears.

4) work in progress

5) no message into dmesg nor /var/log/messages

6) I also tried to run an alsa program but error did not happen even after some days. Maybe the protocol is not equaly the same so error did not appear.

Season's greetings

Hi,

The fact that it appears on ubuntu 32 bits is indeed a good step.
But, unfortunately, valgrind founds nothings...


1) I would add a few logs in ALSA_PlayDevice.

errno = 0;
fprintf(stderr, "call ALSA_PlayDevice\n");

while () {
...
perror("before ALSA_snd_pcm_writei");
call to writei
perror("after ALSA_snd_pcm_writei");
...
perror("before ASLA_snd_pcm_recover");
call to recover
perror("after ASLA_snd_pcm_recover");
...
}

+ try to get the log in a file :)


2/ I would try also commenting out the FIXME "ALSA_snd_pcm_wait".

3/ would try also to update linux kernel package (do a uname -a before/after to know the version before/after).

4/ update alsa. (As you said work-in-progress).

Season's greetings too !

About the ALSA testcase, it might be important set the same initialisation as SDL.

see the initialisation part : 
- Set the number of channels
- Set the buffer size, in samples
- Set the software parameters
- Set the audio rate
- Switch to blocking mode for playback

In fact, SDL is doing pretty much the same thing as the simple testcase of alsa.
Except for the initialisation which is more detailled.

I suspect this is an ALSA driver or libasound bug, and not an SDL bug, but the comment on Bug #2882 suggests there are cases where CPU load spikes after awhile on some drivers, and maybe this is triggering the same thing?

--ryan.

Dear Ryan,

I contacted ALSA on their #IRC a month ago, and they think that it is a 
driver issue.
The problem I am facing is a manufacturer driver that they asked me to 
contact them and I am actually waiting for their answer. In the mean 
time, i am testing an i2s driver and hope that the new Linux i got 
solves the problem.

Thank you for your consideration and your time.
Sincerely,

Note,

You said you reproduced the problem with a Ubuntu 32 bits machine.
In this configuration, there is no custom driver involved.

Yes Sylvain is right.

Perhaps these two drivers got the same base.

I think there can be many causes : bug in ALSA, bug in Kernel, bug in driver. Maybe in an old version of These. Can be a combination of several things also.
You also think of a common driver base problem.

Currently, it still might be in SDL (even if it seems less and less probable).


So, I would suggest to try to reduce the Scope, by excluding SDL.
I mean to make an ALSA-only example to reproduce this issue.

I think, you already started to do that. But you need to dump the parameter that SDL sets to ALSA, then modify the ALSA sample to have the same configuration.


This is important, because it can first help to proove that the bug is not in SDL.
And also, it will be usefull for the ALSA team to debug it!

This looks like an ALSA driver bug. Please reopen it if you find it's really an issue in SDL.

Thanks!