alsa driver, repeat playback of buffer contents

alsa driver, repeat playback of buffer contents

[random.bits]

I have been reading up on the alsa driver. I would like 
to have the alsa driver play a small pcm sound bite 
over and over without have to re-write it to the 
device.

By small, I mean 1.9K in length. I have followed the 
examples enough to get it to play the sound bite once, 
but I cannot figure out how to get it to play it 
multiple times without having to make another call to 
snd_pcm_writei() again.

This sound will play on in the background, while other 
cpu, data bus, and disk intensive work is being 
performed. 

Thank you for any pointers, tips or help.

Mark



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: alsa driver, repeat playback of buffer contents

[Lee Revell]

On Mon, 2005-03-14 at 15:30 -0500, random.bits wrote:
> I have been reading up on the alsa driver. I would like 
> to have the alsa driver play a small pcm sound bite 
> over and over without have to re-write it to the 
> device.
> 
> By small, I mean 1.9K in length. I have followed the 
> examples enough to get it to play the sound bite once, 
> but I cannot figure out how to get it to play it 
> multiple times without having to make another call to 
> snd_pcm_writei() again.

Why in the heck are you using write() instead of mmap()?

Lee



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: alsa driver, repeat playback of buffer contents

[Måns Rullgård]

Lee Revell <rlrevell@joe-job.com> writes:

> On Mon, 2005-03-14 at 15:30 -0500, random.bits wrote:
>> I have been reading up on the alsa driver. I would like 
>> to have the alsa driver play a small pcm sound bite 
>> over and over without have to re-write it to the 
>> device.
>> 
>> By small, I mean 1.9K in length. I have followed the 
>> examples enough to get it to play the sound bite once, 
>> but I cannot figure out how to get it to play it 
>> multiple times without having to make another call to 
>> snd_pcm_writei() again.
>
> Why in the heck are you using write() instead of mmap()?

snd_pcm_writei() often uses mmap() behind the scenes.

-- 
Måns Rullgård
mru@inprovide.com



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: alsa driver, repeat playback of buffer contents

[Lee Revell]

On Mon, 2005-03-14 at 23:20 +0100, Måns Rullgård wrote:
> Lee Revell <rlrevell@joe-job.com> writes:
> 
> > On Mon, 2005-03-14 at 15:30 -0500, random.bits wrote:
> >> I have been reading up on the alsa driver. I would like 
> >> to have the alsa driver play a small pcm sound bite 
> >> over and over without have to re-write it to the 
> >> device.
> >> 
> >> By small, I mean 1.9K in length. I have followed the 
> >> examples enough to get it to play the sound bite once, 
> >> but I cannot figure out how to get it to play it 
> >> multiple times without having to make another call to 
> >> snd_pcm_writei() again.
> >
> > Why in the heck are you using write() instead of mmap()?
> 
> snd_pcm_writei() often uses mmap() behind the scenes.
> 

Right, but AFAICT mmap() should not call write() behind the scenes
(unless you use the plug layer?).  So if you want to be sure to avoid
unnecessary copying you should just use mmap() directly.

Or am I wrong?  Anyway, the JACK ALSA driver always uses mmap() for
example.

Lee



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: alsa driver, repeat playback of buffer contents

[Mark Cannon]

I looked at using the mmap() version, and in fact I 
implemented it. It's easy to use, and it is the better 
way to do it, yet I do not see how it solves my 
problem. 

How can I send down a short PCM stream, and have the 
hardware repeat it until told to stop?

Mark

On Monday 14 March 2005 19:20, Lee Revell wrote:
> On Mon, 2005-03-14 at 23:20 +0100, Måns Rullgård 
wrote:
> > Lee Revell <rlrevell@joe-job.com> writes:
> > > On Mon, 2005-03-14 at 15:30 -0500, random.bits 
wrote:
> > >> I have been reading up on the alsa driver. I
> > >> would like to have the alsa driver play a small
> > >> pcm sound bite over and over without have to
> > >> re-write it to the device.
> > >>
> > >> By small, I mean 1.9K in length. I have
> > >> followed the examples enough to get it to play
> > >> the sound bite once, but I cannot figure out
> > >> how to get it to play it multiple times without
> > >> having to make another call to snd_pcm_writei()
> > >> again.
> > >
> > > Why in the heck are you using write() instead of
> > > mmap()?
> >
> > snd_pcm_writei() often uses mmap() behind the
> > scenes.
>
> Right, but AFAICT mmap() should not call write()
> behind the scenes (unless you use the plug layer?). 
> So if you want to be sure to avoid unnecessary
> copying you should just use mmap() directly.
>
> Or am I wrong?  Anyway, the JACK ALSA driver always
> uses mmap() for example.
>
> Lee
>
>
>
> ----------------------------------------------------
>--- SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT
> Products from real users. Discover which products
> truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=cl
>ick _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-de
>vel

-- 
Mark Cannon
VP Engineering
Viewnyx Corporation


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

Re: Re: alsa driver, repeat playback of buffer contents

[Lee Revell]

On Mon, 2005-03-14 at 20:14 -0500, Mark Cannon wrote:
> I looked at using the mmap() version, and in fact I 
> implemented it. It's easy to use, and it is the better 
> way to do it, yet I do not see how it solves my 
> problem. 
> 

It doesn't, sorry.  Did not mean to hijack your thread.

> How can I send down a short PCM stream, and have the 
> hardware repeat it until told to stop?
> 

Anyone?

Lee



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: alsa driver, repeat playback of buffer contents

[Jaroslav Kysela]

On Mon, 14 Mar 2005, Mark Cannon wrote:

> How can I send down a short PCM stream, and have the 
> hardware repeat it until told to stop?

You must always copy the data to right place in the ring buffer unless
the sound fragment has not exact (or multiple) size of ring buffer.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: alsa driver, repeat playback of buffer contents

[Clemens Ladisch]

Lee Revell wrote:
> On Mon, 2005-03-14 at 23:20 +0100, Måns Rullgård wrote:
> > Lee Revell <rlrevell@joe-job.com> writes:
> > > Why in the heck are you using write() instead of mmap()?
> >
> > snd_pcm_writei() often uses mmap() behind the scenes.
>
> Right, but AFAICT mmap() should not call write() behind the scenes
> (unless you use the plug layer?).  So if you want to be sure to avoid
> unnecessary copying you should just use mmap() directly.

mmap() is only a win if the code that generates/loads the audio data
can write directly to the mapped buffer.  If the audio data is just
copied from elsewhere (i.e., with memcpy), there is no difference to
using snd_pcm_writei(), and, additionally, you can avoid having to
handle wrapping at the buffer boundary.


Regards,
Clemens



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: alsa driver, repeat playback of buffer contents

[random.bits]

I started to follow up on Jaroslav's  advice. 

I am opening the "hw" pcm device using snd_pcm_open in 
order to address the base hardware.

I use "snd_pcm_hw_params_get_buffer" to determine the 
buffer size (which I presume is the hardware ring 
buffer). If I map to this buffer and then fill it with 
the sound exactly, then commit it, it just plays once. 
I put my process into wait state by using sleep(1) 
calls. 
How can I get the hardware to continue to play using 
the data in the ring buffer?

Thanks,
Mark

On Tuesday 15 March 2005 02:49, Jaroslav Kysela wrote:
> On Mon, 14 Mar 2005, Mark Cannon wrote:
> > How can I send down a short PCM stream, and have
> > the hardware repeat it until told to stop?
>
> You must always copy the data to right place in the
> ring buffer unless the sound fragment has not exact
> (or multiple) size of ring buffer.
>
> 						Jaroslav
>
> -----
> Jaroslav Kysela <perex@suse.cz>
> Linux Kernel Sound Maintainer
> ALSA Project, SUSE Labs



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: alsa driver, repeat playback of buffer contents

[Jaroslav Kysela]

On Tue, 15 Mar 2005, random.bits wrote:

> How can I get the hardware to continue to play using 
> the data in the ring buffer?

Use no-xrun mode (set stop_threshold to boundary).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: alsa driver, repeat playback of buffer contents

[random.bits]

Sorry, I replied to your earlier message before seeing 
this message.

I worked my way through the documentation looking at 
no-xrun mode and stop_threshold values. 

When I read the stop_threshold after setting the buffer 
to 471 frames (length of pcm stream I want to repeat 
is 1884 bytes, 11025 sampling, the concept of periods 
is confusing me at the moment, but I used 1), the 
stop_threshold is also set to 471. I then read the 
boundary value and its set to 1975517184. 

If I understand correctly, if I set the stop_threshold 
to this value, the sound should continue to repeat.

It does not repeat the sound. Here is my debug output, 
it shows initial and final settings as the program is 
set up. Then the data is sent to the buffer for 
playback.  Followed by a stream status output. I can 
post the source code if you want, but I figure I made 
a mistake with the setup.

<debug output from alsarepeat.c, for pcm device "hw">
On opening the device, the hw parameters are:
ACCESS:  MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT:  S16_LE S32_LE
SUBFORMAT:  STD
SAMPLE_BITS: [16 32]
FRAME_BITS: [32 64]
CHANNELS: 2
RATE: [8000 48000]
PERIOD_TIME: (83 2048000]
PERIOD_SIZE: [4 16384]
PERIOD_BYTES: [32 131072]
PERIODS: [1 1024]
BUFFER_TIME: (83 2048000]
BUFFER_SIZE: [4 16384]
BUFFER_BYTES: [32 65536]
TICK_TIME: 1000

HW parameters are now:
ACCESS:  RW_INTERLEAVED
FORMAT:  S16_LE
SUBFORMAT:  STD
SAMPLE_BITS: 16
FRAME_BITS: 32
CHANNELS: 2
RATE: 11025
PERIOD_TIME: (42721 42722)
PERIOD_SIZE: 471
PERIOD_BYTES: 1884
PERIODS: 1
BUFFER_TIME: (42721 42722)
BUFFER_SIZE: 471
BUFFER_BYTES: 1884
TICK_TIME: 1000

The initial software parameters are:
start_mode: DATA
xrun_mode: STOP
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 471
xfer_align: 471
silence_threshold: 0
silence_size: 0
boundary: 1975517184

SW parameters are now set to:
start_mode: DATA
xrun_mode: NONE
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 471
xfer_align: 471
silence_threshold: 0
silence_size: 0
boundary: 1975517184

Stream status is
state       : RUNNING
trigger_time: 1110922148.974638000
tstamp      : 1110922149.272647000
delay       : 470
avail       : 1
avail_max   : 472



On Tuesday 15 March 2005 13:49, Jaroslav Kysela wrote:
> On Tue, 15 Mar 2005, random.bits wrote:
> > How can I get the hardware to continue to play
> > using the data in the ring buffer?
>
> Use no-xrun mode (set stop_threshold to boundary).
>
> 						Jaroslav
>
> -----
> Jaroslav Kysela <perex@suse.cz>
> Linux Kernel Sound Maintainer
> ALSA Project, SUSE Labs
>
>
> ----------------------------------------------------
>--- SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT
> Products from real users. Discover which products
> truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=cl
>ick _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-de
>vel


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click