PCM questions

PCM questions

[Ove Kaaven]

Okay, whoever says ALSA is greater than OSS, I'm trying to act on your
assertions, so here are a few questions.

I have the primary PCM configured with silence_threshold set to zero and
silence_size set to MAXINT. This condition is documented as "The whole
ring buffer is filled with silence at start. Later, only just processed
area is filled with silence."

When is "start"? Is it snd_pcm_prepare, or snd_pcm_start? If it's the
latter, it's not too useful, as I currently snd_pcm_prepare, fill the
mmap buffer with sounds, then run snd_pcm_start. Right now when I do
that, the beginning of the sound effect that triggers snd_pcm_start is
silent (but more gets streamed into the mmap buffer later on, and that
is heard). With ALSA's oddball mmap scheme it's not like I could just
easily do the silence processing myself, so it would be nice if ALSA's
would do the right thing.

And is there a way to query what the current application frame position
is, without tracking it myself? Have to do a lot of rewinds (and
forwards) here to add more sound effects to the mmap buffer and such,
and being able to sanity-check the offsets would probably be nice.

And for sound cards capable of hardware mixing, is there a way to have
two PCMs that share a buffer, but can be still be started and stopped
independently? For example, if I've loaded an explosion sound into a PCM
buffer, how can I start a lot of explosion sounds, without wasting a lot
of RAM? Perhaps there's also a way to specify that this sound should be
loaded into the sound card's onboard memory, instead of streamed from
system RAM?




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: PCM questions

[Jaroslav Kysela]

On Thu, 4 Mar 2004, Ove Kaaven wrote:

> Okay, whoever says ALSA is greater than OSS, I'm trying to act on your
> assertions, so here are a few questions.
> 
> I have the primary PCM configured with silence_threshold set to zero and
> silence_size set to MAXINT. This condition is documented as "The whole
> ring buffer is filled with silence at start. Later, only just processed
> area is filled with silence."
> 
> When is "start"? Is it snd_pcm_prepare, or snd_pcm_start? If it's the
> latter, it's not too useful, as I currently snd_pcm_prepare, fill the

The silence is filled at snd_pcm_start(). This mode is special one for
our direct plugins. I don't think that other code need to use this mode.

> mmap buffer with sounds, then run snd_pcm_start. Right now when I do
> that, the beginning of the sound effect that triggers snd_pcm_start is
> silent (but more gets streamed into the mmap buffer later on, and that
> is heard). With ALSA's oddball mmap scheme it's not like I could just
> easily do the silence processing myself, so it would be nice if ALSA's
> would do the right thing.

You can do everything like in OSS. It seems that you don't understand 
API concepts. Forget to ALSA silence extensions and do it yourself
if you wish (simply put stream into no-xrun mode and use rewind and 
forward functions to move the actual write pointer). This mode is same
as OSS offers.

> And is there a way to query what the current application frame position
> is, without tracking it myself? Have to do a lot of rewinds (and
> forwards) here to add more sound effects to the mmap buffer and such,
> and being able to sanity-check the offsets would probably be nice.

These pointers are hidden, so you need to track the actual position in 
application (which is not too difficult). Note that most of application
does not ugly things with the DMA buffer, so they don't require to know
the hardware pointers directly.

> And for sound cards capable of hardware mixing, is there a way to have
> two PCMs that share a buffer, but can be still be started and stopped
> independently? For example, if I've loaded an explosion sound into a PCM
> buffer, how can I start a lot of explosion sounds, without wasting a lot
> of RAM? Perhaps there's also a way to specify that this sound should be
> loaded into the sound card's onboard memory, instead of streamed from
> system RAM?

It is wavetable synthesizer API not PCM API. This part of ALSA is still 
in the development phase.

						Jaroslav

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


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: PCM questions

[Ove Kaaven]

tor, 04.03.2004 kl. 17.33 skrev Jaroslav Kysela:
> The silence is filled at snd_pcm_start(). This mode is special one for
> our direct plugins. I don't think that other code need to use this mode.

Well, perhaps you don't think so, but the code we're trying to use here
does work much like any "direct plugins"... mixes several dynamic
streams, probably much like the dmix plugin does.

> > mmap buffer with sounds, then run snd_pcm_start. Right now when I do
> > that, the beginning of the sound effect that triggers snd_pcm_start is
> > silent (but more gets streamed into the mmap buffer later on, and that
> > is heard). With ALSA's oddball mmap scheme it's not like I could just
> > easily do the silence processing myself, so it would be nice if ALSA's
> > would do the right thing.
> 
> You can do everything like in OSS. It seems that you don't understand 
> API concepts. Forget to ALSA silence extensions and do it yourself
> if you wish (simply put stream into no-xrun mode and use rewind and 
> forward functions to move the actual write pointer).

Are you saying that the design of the API is very different from what is
considered the appropriate way to do things, so that using the API in
awkward ways are endorsed, while using all the API features in
straightforward ways, the way it is apparently designed, is discouraged?

Well, concerns of having to resort to messy application-side code to
reimplement ALSA API features aside, there's also the issue of whether
to rewind to before the playing position, or rather to forward to one
buffer size after the playing position, to insert the silence, since for
the ALSA API, there's a difference. But perhaps forward makes most
sense. I guess I can do that.

> > And is there a way to query what the current application frame position
> > is, without tracking it myself? Have to do a lot of rewinds (and
> > forwards) here to add more sound effects to the mmap buffer and such,
> > and being able to sanity-check the offsets would probably be nice.
> 
> These pointers are hidden, so you need to track the actual position in 
> application (which is not too difficult). Note that most of application
> does not ugly things with the DMA buffer, so they don't require to know
> the hardware pointers directly.

Okay.

> > And for sound cards capable of hardware mixing, is there a way to have
> > two PCMs that share a buffer, but can be still be started and stopped
> > independently? For example, if I've loaded an explosion sound into a PCM
> > buffer, how can I start a lot of explosion sounds, without wasting a lot
> > of RAM? Perhaps there's also a way to specify that this sound should be
> > loaded into the sound card's onboard memory, instead of streamed from
> > system RAM?
> 
> It is wavetable synthesizer API not PCM API. This part of ALSA is still 
> in the development phase.

But when that gets fully developed, would I have to use the rawmidi API
to do this then?




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: PCM questions

[Jaroslav Kysela]

On Thu, 4 Mar 2004, Ove Kaaven wrote:

> tor, 04.03.2004 kl. 17.33 skrev Jaroslav Kysela:
> > The silence is filled at snd_pcm_start(). This mode is special one for
> > our direct plugins. I don't think that other code need to use this mode.
> 
> Well, perhaps you don't think so, but the code we're trying to use here
> does work much like any "direct plugins"... mixes several dynamic
> streams, probably much like the dmix plugin does.

Yes, but note that you can still enable the "auto silence" mechanism 
which does empty buffer at snd_pcm_start().

> > > mmap buffer with sounds, then run snd_pcm_start. Right now when I do
> > > that, the beginning of the sound effect that triggers snd_pcm_start is
> > > silent (but more gets streamed into the mmap buffer later on, and that
> > > is heard). With ALSA's oddball mmap scheme it's not like I could just
> > > easily do the silence processing myself, so it would be nice if ALSA's
> > > would do the right thing.
> > 
> > You can do everything like in OSS. It seems that you don't understand 
> > API concepts. Forget to ALSA silence extensions and do it yourself
> > if you wish (simply put stream into no-xrun mode and use rewind and 
> > forward functions to move the actual write pointer).
> 
> Are you saying that the design of the API is very different from what is
> considered the appropriate way to do things, so that using the API in
> awkward ways are endorsed, while using all the API features in
> straightforward ways, the way it is apparently designed, is discouraged?

Not really. I don't know, what you're trying to do. The silence extension
can be used to silence played area automatically from the interrupt 
contents. If you set "silence_threshold" and "silence_size" to 
buffer_size, then the whole _unused_ portion of the ring buffer will be 
filled with silence. Perhaps, that's the behaviour what you expect.

I wanted to note, that we can do everything like OSS API does.

> Well, concerns of having to resort to messy application-side code to
> reimplement ALSA API features aside, there's also the issue of whether
> to rewind to before the playing position, or rather to forward to one
> buffer size after the playing position, to insert the silence, since for
> the ALSA API, there's a difference. But perhaps forward makes most
> sense. I guess I can do that.

I don't understand.

> > It is wavetable synthesizer API not PCM API. This part of ALSA is still
> > in the development phase.
> 
> But when that gets fully developed, would I have to use the rawmidi API
> to do this then?

I think that sequencer API is more appropriate, but as I said, we don't 
have a clear design at this time. It's also possible that we will hide 
these things in alsa-lib and the kernel API will be hardware specific 
using the hwdep interface.

						Jaroslav

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


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: PCM questions

[Takashi Iwai]

At Thu, 04 Mar 2004 17:02:09 +0100,
Ove Kaaven wrote:
> 
> And for sound cards capable of hardware mixing, is there a way to have
> two PCMs that share a buffer, but can be still be started and stopped
> independently?

such a hardware also doesn't share the "buffer".
it supports the h/w mixing but each stream needs to have indepednet
buffer.

>  For example, if I've loaded an explosion sound into a PCM
> buffer, how can I start a lot of explosion sounds, without wasting a lot
> of RAM? Perhaps there's also a way to specify that this sound should be
> loaded into the sound card's onboard memory, instead of streamed from
> system RAM?

it sounds like wavetable function.  currently, it's designed for
MIDI-like apps, but it might be used for games, too.
anyway, it's under development (for a long long time)...

or, with PCM API, you can open several PCMs in a single application.
if the number of voices are limited, it won't be too heavy.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: PCM questions

[Takashi Iwai]

At Thu, 4 Mar 2004 19:43:58 +0100 (CET),
Jaroslav wrote:
> 
> > > It is wavetable synthesizer API not PCM API. This part of ALSA is still
> > > in the development phase.
> > 
> > But when that gets fully developed, would I have to use the rawmidi API
> > to do this then?
> 
> I think that sequencer API is more appropriate, but as I said, we don't 
> have a clear design at this time. It's also possible that we will hide 
> these things in alsa-lib and the kernel API will be hardware specific 
> using the hwdep interface.

i feel hwdep would be more appropriate.

i guess he wants the sound engine, mixing of several streams and
running efficiently (almost in background) for games, etc.
it's less music-oriented, but would need just a sample load and
loop playback function (with panning, volume effect if possible).
at least, it wouldn't be too difficult to implement it for emu10k1
(and maybe trident and ymfpci, too, if the sample size is small).


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: PCM questions

[Ove Kaaven]

tor, 04.03.2004 kl. 19.43 skrev Jaroslav Kysela:
> Not really. I don't know, what you're trying to do. The silence extension
> can be used to silence played area automatically from the interrupt 
> contents. If you set "silence_threshold" and "silence_size" to 
> buffer_size, then the whole _unused_ portion of the ring buffer will be 
> filled with silence. Perhaps, that's the behaviour what you expect.

Well, I was afraid that mode would not work well when I rewinded to add
more sfx, I would risk getting any existing sfx in the buffer cleared.
Or wouldn't I?

> > Well, concerns of having to resort to messy application-side code to
> > reimplement ALSA API features aside, there's also the issue of whether
> > to rewind to before the playing position, or rather to forward to one
> > buffer size after the playing position, to insert the silence, since for
> > the ALSA API, there's a difference. But perhaps forward makes most
> > sense. I guess I can do that.
> 
> I don't understand.

Well, for example, if the buffer size is 16384 frames, the app frame
position is 24576, and the currently playing position is 20480 (so that
snd_pcm_delay returns 4096). Now I want to clear the last 4096 frames
that completed playing. Do I

1) call snd_pcm_rewind(8192), so that app frame position is 16384, which
is logically behind play position (and in a xrun condition)

or

2) call snd_pcm_forward(8192), so that app frame position is 32768,
which is logically after play position (and seeking past potentially
invalid data to get there)

In both cases, begin_mmap should return a pointer at the beginning of
the buffer and let me clear the desired area of it. But it might make a
difference to xrun recovery, auto-silence, and who knows what else...

But I'll just go for 2), it seems to be most straightforward to achieve
with the current abstraction in our code.

> > > It is wavetable synthesizer API not PCM API. This part of ALSA is still
> > > in the development phase.
> > 
> > But when that gets fully developed, would I have to use the rawmidi API
> > to do this then?
> 
> I think that sequencer API is more appropriate, but as I said, we don't 
> have a clear design at this time. It's also possible that we will hide 
> these things in alsa-lib and the kernel API will be hardware specific 
> using the hwdep interface.

Hmm.




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: PCM questions

[Ove Kaaven]

tor, 04.03.2004 kl. 19.47 skrev Takashi Iwai:
> or, with PCM API, you can open several PCMs in a single application.
> if the number of voices are limited, it won't be too heavy.

Hmm. I suspect that doing that would not be that much better than
software mixing unless I can use arbitrary buffer sizes on those PCMs
(so that I can just play a sfx of any length in it, loop it, etc,
without having to "babysit" it and constantly stream new data to it).
But I suppose I could look into it...




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: PCM questions

[Jaroslav Kysela]

On Fri, 5 Mar 2004, Giuliano Pochini wrote:

> required features, at least the basic ones. Device dependent
> stuff is not a good idea IMHO.

The abstraction will be in alsa-lib, so the application will have common 
access to this API. But the hardware is too much different in this area
and we don't want to put much code in kernel, so alsa-lib will handle
the differences.

						Jaroslav

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


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: PCM questions

[Giuliano Pochini]

On 04-Mar-2004 Takashi Iwai wrote:

>> > > It is wavetable synthesizer API not PCM API. This part of ALSA is still
>> > > in the development phase.
>> >
>> > But when that gets fully developed, would I have to use the rawmidi API
>> > to do this then?
>>
>> I think that sequencer API is more appropriate, but as I said, we don't
>> have a clear design at this time. It's also possible that we will hide
>> these things in alsa-lib and the kernel API will be hardware specific
>> using the hwdep interface.
>
> i feel hwdep would be more appropriate.
>
> i guess he wants the sound engine, mixing of several streams and
> running efficiently (almost in background) for games, etc.
> it's less music-oriented, but would need just a sample load and
> loop playback function (with panning, volume effect if possible).
> at least, it wouldn't be too difficult to implement it for emu10k1
> (and maybe trident and ymfpci, too, if the sample size is small).

On the Amiga :) it was simple. You only need to tell the hw
to play a block of data at given sample rate, volume, etc.
But most of the cards can't do that. I think one good solution
is to run an "sfx mixer" in a separate thread. That mixer
must provide emulation code if the hardware lacks some of the
required features, at least the basic ones. Device dependent
stuff is not a good idea IMHO.


--
Giuliano.


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: PCM questions

[James Wright]

On Fri, 05 Mar 2004 10:01:28 +0100 (CET)
Giuliano Pochini <pochini@shiny.it> wrote:

> On the Amiga :) it was simple. You only need to tell the hw
> to play a block of data at given sample rate, volume, etc.
> But most of the cards can't do that. I think one good solution
> is to run an "sfx mixer" in a separate thread. That mixer
> must provide emulation code if the hardware lacks some of the
> required features, at least the basic ones. Device dependent
> stuff is not a good idea IMHO.
> 

   I am writing a custom sound lib for us to develop games on Linux, I
have tried to make it as simple as possible, (much like what te Amiga
did actually), ao you can just play a sound using an assingned number
for each sound, a rate and a volume. I use my own software mixing to 
provide 8 sfx channels, and mix them into a single PCM channel, at
the desired rates and volumes. Software mixing hardly uses any CPU
time at all (if you can write decent code) and i can't understand why
you NEED hardware mixing for your application (games)...


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: PCM questions

[Jaroslav Kysela]

On Thu, 4 Mar 2004, Ove Kaaven wrote:

> tor, 04.03.2004 kl. 19.43 skrev Jaroslav Kysela:
> > Not really. I don't know, what you're trying to do. The silence extension
> > can be used to silence played area automatically from the interrupt 
> > contents. If you set "silence_threshold" and "silence_size" to 
> > buffer_size, then the whole _unused_ portion of the ring buffer will be 
> > filled with silence. Perhaps, that's the behaviour what you expect.
> 
> Well, I was afraid that mode would not work well when I rewinded to add
> more sfx, I would risk getting any existing sfx in the buffer cleared.
> Or wouldn't I?

Yes, of course. If you rewind, you must fill all next samples again in 
this case. The auto-silence was designed to silence the buffer ahead
to not write a broken samples to output when a xrun condition occurs.

> > > Well, concerns of having to resort to messy application-side code to
> > > reimplement ALSA API features aside, there's also the issue of whether
> > > to rewind to before the playing position, or rather to forward to one
> > > buffer size after the playing position, to insert the silence, since for
> > > the ALSA API, there's a difference. But perhaps forward makes most
> > > sense. I guess I can do that.
> > 
> > I don't understand.
> 
> Well, for example, if the buffer size is 16384 frames, the app frame
> position is 24576, and the currently playing position is 20480 (so that
> snd_pcm_delay returns 4096). Now I want to clear the last 4096 frames
> that completed playing. Do I
> 
> 1) call snd_pcm_rewind(8192), so that app frame position is 16384, which
> is logically behind play position (and in a xrun condition)

You cannot do that. You cannot rewind behing the actual hardware pointer.

> or
> 
> 2) call snd_pcm_forward(8192), so that app frame position is 32768,
> which is logically after play position (and seeking past potentially
> invalid data to get there)
> 
> In both cases, begin_mmap should return a pointer at the beginning of
> the buffer and let me clear the desired area of it. But it might make a
> difference to xrun recovery, auto-silence, and who knows what else...
> 
> But I'll just go for 2), it seems to be most straightforward to achieve
> with the current abstraction in our code.

Yes, it's only correct way.

I also extended the "auto-silence" function in driver in our CVS.
Now, the code detects the written samples so snd_pcm_start() doesn't
silence the whole ring buffer in this case.

Here is the patch for driver:

Index: pcm_lib.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/core/pcm_lib.c,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -r1.48 -r1.49
--- pcm_lib.c	2 Mar 2004 15:32:35 -0000	1.48
+++ pcm_lib.c	6 Mar 2004 10:02:48 -0000	1.49
@@ -67,8 +67,11 @@
 			frames = runtime->silence_size;
 	} else {
 		if (new_hw_ptr == ULONG_MAX) {	/* initialization */
-			runtime->silence_filled = 0;
-			runtime->silence_start = runtime->control->appl_ptr;
+			snd_pcm_sframes_t avail = snd_pcm_playback_hw_avail(runtime);
+			runtime->silence_filled = avail > 0 ? avail : 0;
+			runtime->silence_start = (runtime->status->hw_ptr +
+						  runtime->silence_filled) %
+						 runtime->boundary;
 		} else {
 			ofs = runtime->status->hw_ptr;
 			frames = new_hw_ptr - ofs;

						Jaroslav

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


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: PCM questions

[Ove Kaaven]

lør, 06.03.2004 kl. 11.10 skrev Jaroslav Kysela:
> I also extended the "auto-silence" function in driver in our CVS.
> Now, the code detects the written samples so snd_pcm_start() doesn't
> silence the whole ring buffer in this case.
> 
> Here is the patch for driver:

OK, thanks, may be useful for future projects.

I have a new question. How can I handle a buffer wraparound with
snd_pcm_mmap_begin and snd_pcm_mmap_commit? It seems that currently, if
the app frame pos is near the end of the buffer, the returned number of
mapped frames is apparently only up to the end of the buffer. But the
code that fills the buffer will want to handle the wraparound itself, so
I would like to return the requested number of frames to the code, and
let it do its own wraparound to offset=0 when the end of buffer is
reached. Is it safe to do something like calling snd_pcm_mmap_begin
twice to achieve this, then snd_pcm_mmap_commit twice after the sound
code has filled the buffer up?




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

undefined reference to `snd_pcm_hw_params_sizeof'

[Tim Hollingsworth]

Hi

I'm a newbie with alsa and rusty with c.  I am trying to get a basic 
pcm application going.  I have:

	#include <alsa/asoundlib.h>

but when I try to:

	snd_pcm_hw_params_alloca(&hwparams);

I get:

/tmp/ccJB6E1d.o(.text+0x18): In function `initSound':
: undefined reference to `snd_pcm_hw_params_sizeof'
/tmp/ccJB6E1d.o(.text+0x31): In function `initSound':
: undefined reference to `snd_pcm_hw_params_sizeof'
collect2: ld returned 1 exit status

any help appreciated
cheers
Tim

Full source so far:

     #include <alsa/asoundlib.h>

     /* Handle for the PCM device */
     snd_pcm_t *pcm_handle;

     /* Playback stream */
     snd_pcm_stream_t stream = SND_PCM_STREAM_PLAYBACK;

     /* This structure contains information about    */
     /* the hardware and can be used to specify the  */
     /* configuration to be used for the PCM stream. */
     snd_pcm_hw_params_t *hwparams;

     /* Name of the PCM device, like plughw:0,0          */
     /* The first number is the number of the soundcard, */
     /* the second number is the number of the device.   */
     char *pcm_name;


int initSound(int channels, int sampleRate, int framebytes)
{

     /* Init pcm_name. Of course, later you */
     /* will make this configurable ;-)     */
     pcm_name = strdup("plughw:0,0");


     /* Allocate the snd_pcm_hw_params_t structure on the stack. */
     snd_pcm_hw_params_alloca(&hwparams);
}

main(){}



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: undefined reference to `snd_pcm_hw_params_sizeof'

[Jaroslav Kysela]

On Wed, 17 Mar 2004, Tim Hollingsworth wrote:

> Hi
> 
> I'm a newbie with alsa and rusty with c.  I am trying to get a basic 
> pcm application going.  I have:
> 
> 	#include <alsa/asoundlib.h>
> 
> but when I try to:
> 
> 	snd_pcm_hw_params_alloca(&hwparams);
> 
> I get:
> 
> /tmp/ccJB6E1d.o(.text+0x18): In function `initSound':
> : undefined reference to `snd_pcm_hw_params_sizeof'
> /tmp/ccJB6E1d.o(.text+0x31): In function `initSound':
> : undefined reference to `snd_pcm_hw_params_sizeof'
> collect2: ld returned 1 exit status

gcc -lasound <your_c_file>

						Jaroslav

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


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click