On Fri, 3 Jan 2020 12:49:36 +0100
"R.Wieser"  wrote:

>Jim,
>
>> I see you've not had any response to your query.
>
>Indeed. :-\
>
>> I'm not surprised. I don't think there are many people who have
>> programmed the ALSA interface,
>
>Not ?   In that case, how does everybody else get user-defined sounds from
>their speakers ?    Is there another approach available ?
>
>> and you have probably found there are not many tutorials on how to use it.
>
>Indeed again.   Some code snippets, a few "compile this" programs, and a
>list of pcm related functions.  Thats about it.
>
>> but it is Soooo.... complicated
>
>The basic setup, as presented in that linke I provided, looks fairly simple
>to me.  Its just that when I make small changes (like changing the sample
>rate) it refuses to work (change) in a way I can make sense of. :-\
>
>> You just might have got me interested in trying again.
>
>So ?    You will have the solution for me tomorrow ? :-D (yes, that was a
>joke.  No, really :-) )
>
>> I hope you have made progress.
>
>Just this morning I tried some super-simple code using
>"snd_pcm_set_params( )" and a single buffer (
>https://stackoverflow.com/questions/40399046/how-to-play-short-tones-with-alsa
)
>and found out that by lowering with the latency parameter value (the last
>one) I could get the same "cut short" effect my origionally mentioned code
>suffers from.
>
>That made me think that maybe the internal ALSA buffer empties before a new
>set of data (my programs buffer) is written into it ...    Which is as far
>as I currently got.
>
>Though no idea why, when I put a seconds long "usleep( )" before the
>"snd_pcm_drain( )", the whole sound is played without me hearing any kind of
>hickups.
>
>
>And again, if you know of another, more dependable way to generate sounds in
>a C program than I would really like to know (as in a different API).
>
>Regards,
>Rudy Wieser
>
>P.s.
>I tried to set a bigger internal buffer
>(snd_pcm_hw_params_set_buffer_size_near( ) ), but could not get it to change
>from 32768.
>
>

ALSA is quite complicated at first. It's some time since I've worked on it,
but this is what I found out.

It is a series of negotiations. You can't just say I want 2 channels at 16bit,
for example. You make a request, and based on the hardware driver and ALSA's
internal capabilities you are told what you've got.

Number of channels is a particular GOTCHA as it seems you'll usually get back
whatever is available regardless of what you ask for so you have to watch out
for buffer sizes, and channel numbers.

Also, 16bit usually seems to be done as interleaved short integers, which means
you have to pair up adjacent channels (with one of the 16bit shifted).

HTH

--
W J G

--- SoupGate-Win32 v1.05