Sound streaming application: which device to use?

Sound streaming application: which device to use?

[Lex Wassenberg]

Hi all,

I'm completely new to ALSA, so forgive me if these are newby questions.

I'm working on an application which receives sound chunks via an IP
connection, and it should use the local sound card to make this sound
audible. Up to now it used OSS, but there were some problems with
that, so I'm busy with rewriting the application to ALSA. The sound is
16-bit stereo, sampled at 8000 Hz, and it comes in chunks of 1024
frames. I managed to get things more or less working, but there are
still some things unclear to me.

1. If I open the soundcard with device "default" or device "plughw" I
get good sound, but the device "default" only accepts 1020 frames of
every 1024 that I offer it (as can be seen from the return value of
snd_pcm_writei() ). The device "plughw" nicely accepts all 1024
frames. Why is this? In both cases I have set the sample rate to 8000
via a call to snd_pcm_hw_params_set_rate_near() and the buffer size to
2048 frames via snd_pcm_hw_params_set_buffer_size_near().

2. If I use device "default", there seems to be no obligation to set
the buffer size nor the period size, I still get good sound at the
output. If I use "plughw", I have to set either the buffer size (2048
frames) or the period size (1024 frames), otherwise I get distorted
sound. If I set both (the buffer size being 2048 and the period size
being 1024) I also get distorted sound. Why?

3. If I set the buffer size twice the period size (as above), and ask
the sizes back, ALSA nicely reports the buffer size as being twice the
period size. But if I ask the buffer and period TIMES, they are
reported as being the same: 128000 us!  Huh????

4. The return value of snd_pcm_hw_params_set_rate_near() is sometimes
8000, sometimes 7999, from the very same program. I would expect ALSA
to always return the same value, be it what I request or not, but at
least being deterministic. How can this be?

5. There is another application running on the same target system,
which will sometimes produce audible alarms. However, if my
application is running that other application cannot generate the
alarms, it produces a "resource busy" error. It is clear to me that my
application is using the sound card exclusively, but how can I get it
to allow other applications access to it too? I tried using the device
"dmix", but then my sound is again very distorted.

Hope that somebody can help me out.
Thanks in advance.

Lex

Re: Sound streaming application: which device to use?

[Colin Guthrie]

'Twas brillig, and Lex Wassenberg at 04/06/09 12:28 did gyre and gimble:
> I'm working on an application which receives sound chunks via an IP
> connection, and it should use the local sound card to make this sound
> audible. Up to now it used OSS, but there were some problems with
> that, so I'm busy with rewriting the application to ALSA. The sound is
> 16-bit stereo, sampled at 8000 Hz, and it comes in chunks of 1024
> frames. I managed to get things more or less working, but there are
> still some things unclear to me.

Depending on the use case of your application, have you considered 
writing a pulseaudio module instead.

Pulseaudio already integrates with wireless and network systems for 
audio, notably bluetooth, Apple RAOP/Airtunes, and it's uPnP media 
stuff, RTP streams and it's own network protocol.

It would be fairly easy to hook up a remote device like this and have it 
"play" the sound via pulseuaudio.

You'll be needing some kind of daemon/background process anyway to 
listen on the network so this may be a better construct for you to work 
with rather than having to worry to start your "listener" app.

There may be many reasons why this wouldn't work for you but figured it 
was worth mentioning.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]

Re: Sound streaming application: which device to use?

[Lex Wassenberg]

On Thu, Jun 4, 2009 at 1:28 PM, Lex Wassenberg<lex.wassenberg@gmail.com> wrote:
> Hi all,
>
> I'm completely new to ALSA, so forgive me if these are newby questions.
>
> I'm working on an application which receives sound chunks via an IP
> connection, and it should use the local sound card to make this sound
> audible. Up to now it used OSS, but there were some problems with
> that, so I'm busy with rewriting the application to ALSA. The sound is
> 16-bit stereo, sampled at 8000 Hz, and it comes in chunks of 1024
> frames. I managed to get things more or less working, but there are
> still some things unclear to me.
>
> 1. If I open the soundcard with device "default" or device "plughw" I
> get good sound, but the device "default" only accepts 1020 frames of
> every 1024 that I offer it (as can be seen from the return value of
> snd_pcm_writei() ). The device "plughw" nicely accepts all 1024
> frames. Why is this? In both cases I have set the sample rate to 8000
> via a call to snd_pcm_hw_params_set_rate_near() and the buffer size to
> 2048 frames via snd_pcm_hw_params_set_buffer_size_near().
>
> 2. If I use device "default", there seems to be no obligation to set
> the buffer size nor the period size, I still get good sound at the
> output. If I use "plughw", I have to set either the buffer size (2048
> frames) or the period size (1024 frames), otherwise I get distorted
> sound. If I set both (the buffer size being 2048 and the period size
> being 1024) I also get distorted sound. Why?
>
> 3. If I set the buffer size twice the period size (as above), and ask
> the sizes back, ALSA nicely reports the buffer size as being twice the
> period size. But if I ask the buffer and period TIMES, they are
> reported as being the same: 128000 us!  Huh????
>
> 4. The return value of snd_pcm_hw_params_set_rate_near() is sometimes
> 8000, sometimes 7999, from the very same program. I would expect ALSA
> to always return the same value, be it what I request or not, but at
> least being deterministic. How can this be?
>
> 5. There is another application running on the same target system,
> which will sometimes produce audible alarms. However, if my
> application is running that other application cannot generate the
> alarms, it produces a "resource busy" error. It is clear to me that my
> application is using the sound card exclusively, but how can I get it
> to allow other applications access to it too? I tried using the device
> "dmix", but then my sound is again very distorted.
>
> Hope that somebody can help me out.
> Thanks in advance.
>
> Lex
>

Is there nobody that can help me out on the questions above? I figured
the answer to question 4 (passing a pointer to an uninitialized
integer; I thought the integer was only used for reporting back, which
is not true), but all other questions still stand. Nobody??

Lex

Re: Sound streaming application: which device to use?

[Lee Revell]

On Tue, Jun 9, 2009 at 10:01 AM, Lex Wassenberg<lex.wassenberg@gmail.com> wrote:
> Is there nobody that can help me out on the questions above? I figured
> the answer to question 4 (passing a pointer to an uninitialized
> integer; I thought the integer was only used for reporting back, which
> is not true), but all other questions still stand. Nobody??

You don't provide enough info.  What soundcard?  What distro?  What is
the output of  "aplay -v file.wav" when file.wav is the same audio
format your app uses?

Lee

Re: Sound streaming application: which device to use?

[Lex Wassenberg]

On Wed, Jun 10, 2009 at 4:42 AM, Lee Revell<rlrevell@joe-job.com> wrote:
> On Tue, Jun 9, 2009 at 10:01 AM, Lex Wassenberg<lex.wassenberg@gmail.com> wrote:
>> Is there nobody that can help me out on the questions above? I figured
>> the answer to question 4 (passing a pointer to an uninitialized
>> integer; I thought the integer was only used for reporting back, which
>> is not true), but all other questions still stand. Nobody??
>
> You don't provide enough info.  What soundcard?  What distro?  What is
> the output of  "aplay -v file.wav" when file.wav is the same audio
> format your app uses?
>
> Lee
>

The distro is OpenSuse 10.3 , the soundcard doesn't (or shouldn't)
matter: the application program knows nothing about the soundcard and
it doesn't want to either. It should just use that sound card that is
present on the machine where it runs. I thought that it would be ALSA
that takes care of the particularites of the underlying hardware.
That's why I programmed the device to be "default" or "plughw".

For the requested output of the aplay program I would first have to
find a wave file with the specific format.

Lex

Re: Sound streaming application: which device to use?

[Pavel Hofman]

Lex Wassenberg wrote:
> On Wed, Jun 10, 2009 at 4:42 AM, Lee Revell<rlrevell@joe-job.com> wrote:
>> On Tue, Jun 9, 2009 at 10:01 AM, Lex Wassenberg<lex.wassenberg@gmail.com> wrote:
>>> Is there nobody that can help me out on the questions above? I figured
>>> the answer to question 4 (passing a pointer to an uninitialized
>>> integer; I thought the integer was only used for reporting back, which
>>> is not true), but all other questions still stand. Nobody??
>> You don't provide enough info.  What soundcard?  What distro?  What is
>> the output of  "aplay -v file.wav" when file.wav is the same audio
>> format your app uses?
>>
>> Lee
>>
> 
> The distro is OpenSuse 10.3 , the soundcard doesn't (or shouldn't)
> matter: the application program knows nothing about the soundcard and
> it doesn't want to either. It should just use that sound card that is
> present on the machine where it runs. I thought that it would be ALSA
> that takes care of the particularites of the underlying hardware.
> That's why I programmed the device to be "default" or "plughw".
> 
> For the requested output of the aplay program I would first have to
> find a wave file with the specific format.
> 

Just use sox, it will convert to any format you need. Details man sox, e.g.

sox your.mp3 -r 44100 -b 16 new-44k-16.wav

Pavel.