I copied the example program you referenced. Compiled it and ran

$ time cat /dev/zero | ./simple_alsa_play

real    0m5.028s
user    0m0.396s
sys     0m0.000s

But this is not on a raspberry pi, it's on a PC. But the program compiled
just fine. The whole point of the ALSA setup is that as long as the kernel
has the ALSA support, an alsa program should run. So I would _expect_
the platform to make no difference. But as they say. shit happens!

Whether you compile using geany or whatever or from the command line (as I
did) doesn't make any difference.

Jim

On 2020-01-22, R.Wieser  wrote:
> Hello all,
>
> I've found a simple tutorial here
> http://www.linuxjournal.com/article/6735?page=0,0 and have a bit of a
> problem with listing #3.
>
> First off , when I executed the program it had a long delay executing the
> "snd_pcm_hw_params_set_rate_near()" function, which turned out to be related
> to the "dir" argument not being initialised (with Zero).
>
> #1: I'm using gcc on a Raspberry Pi in geany.  Is there some sort of setting
> I should add to have gcc include code to automatically clear declared
> variables ?
>
> Or should I assume that the code simply isn't complete (would explain a few
> things).
>
> #2: The length out the outputted sample doesn't seem to be five seconds,
> even when the code promises it to be.
>
> 1) I checked that by clearing the buffer and only execute "rc = read(0,
> buffer, size);" when the "loops" counter was zero.   No sound was to be
> heard.
>
> 2) when I added an "usleep()" of a second before the "snd_pcm_drain()" call
> I did hear something (read: the data was there, just not outputted)
>
> 3) I've measure the time starting just befor the loop to just after the
> "snd_pcm_drain()" call using "gettimeofday()" like described here
> https://www.techiedelight.com/find-execution-time-c-program/ , and the
> measured time is indeed less than the promised five seconds.
>
>
> #3: The problem gets even more pronounced when I changed the sampling rate
> from 44100 to 8000.  After that change the sound is outputted for less than
> a single second (time measured using the above method). :-(
>
> Using the same 1) and 2) checks I found that the full five seconds of sound
> data was again there, but those four seconds worth of it just doesn't get
> outputted.
>
>
> Can anyone confirm this behaviour  (read: its just some incomplete example
> code) ?
> And most important: What is missing from that code that causes the sound
> output the be cut-off like that ?
>
> I've been searching my ass off for quite some time now, but have not been
> able to find anything that could shed some light on it. :-(
>
> Regards,
> Rudy Wieser
>
>

--- SoupGate-Win32 v1.05