PCM hw mixing with volume

PCM hw mixing with volume

[Ove Kaaven]

We have some games that want to mix several dynamic sound streams.
That's easy enough at first glance, just snd_pcm_open() for each stream
they want to output (and do software mixing when that fails). However,
it seems that they want each stream to have independent volume and pan
controls.

As far as I can tell, this is possible to do on SB Live and Audigy by
messing with the "EMU10K1 PCM Send" volume controls, but this is pretty
device-specific and few other hw-mixing ALSA drivers seem to have
exposed such a feature. (And software plugins are not of interest.)

Are you planning to standardize such features or design a
device-independent API for it? (And my manager wants to know which ALSA
release this might get implemented in...)




-------------------------------------------------------
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 hw mixing with volume

[Manuel Jander]

Hi,

Aureal Hardware can do this in hardware, but this feature has not been
exposed. I would be interested :D Maybe this could be done using some
well defined  controls. That would be needed for OpenAL support anyway.
Any comments ?

Best Regards

Manuel Jander

On Sun, 2004-03-07 at 10:51, Ove Kaaven wrote:
> We have some games that want to mix several dynamic sound streams.
> That's easy enough at first glance, just snd_pcm_open() for each stream
> they want to output (and do software mixing when that fails). However,
> it seems that they want each stream to have independent volume and pan
> controls.
> 
> As far as I can tell, this is possible to do on SB Live and Audigy by
> messing with the "EMU10K1 PCM Send" volume controls, but this is pretty
> device-specific and few other hw-mixing ALSA drivers seem to have
> exposed such a feature. (And software plugins are not of interest.)
> 
> Are you planning to standardize such features or design a
> device-independent API for it? (And my manager wants to know which ALSA
> release this might get implemented in...)
> 
> 
> 
> 
> -------------------------------------------------------
> 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
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel



-------------------------------------------------------
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 hw mixing with volume

[Jaroslav Kysela]

On Sun, 7 Mar 2004, Ove Kaaven wrote:

> We have some games that want to mix several dynamic sound streams.
> That's easy enough at first glance, just snd_pcm_open() for each stream
> they want to output (and do software mixing when that fails). However,
> it seems that they want each stream to have independent volume and pan
> controls.
> 
> As far as I can tell, this is possible to do on SB Live and Audigy by
> messing with the "EMU10K1 PCM Send" volume controls, but this is pretty
> device-specific and few other hw-mixing ALSA drivers seem to have
> exposed such a feature. (And software plugins are not of interest.)
> 
> Are you planning to standardize such features or design a
> device-independent API for it? (And my manager wants to know which ALSA
> release this might get implemented in...)

I'm working on this issue right now, but I cannot estimate the release 
time, because my work is hightly interrupted with the ALSA maintenance
issues.

Hopefully, the API will be functional in a few months.

						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 hw mixing with volume

[Paul Davis]

>Are you planning to standardize such features or design a
>device-independent API for it? (And my manager wants to know which ALSA
>release this might get implemented in...)

Just a thought on your overall issues with ALSA over the last week.

The kinds of features you seem to expect from hardware didn't exist in
most devices 2 years ago. Its likely that features currently
considered "experimental" in hardware right now (matrix mixing springs
to mind) will become more common 2 years from now.

Does your manager think it wise to be writing software that is so tied
into a particular model of what audio interfaces can do that it will
be obsolete by the time processors run about 4 times as fast as they
do now?

People wrote game engines that did all this "multistream+backfill"
stuff years before any cards provided hardware mixing, and they did
most of it in software on CPU's that were 10-40 times slower than
todays leading edge game-friendly processors. You are going to burn a
lot of time trying to find common ways to access the slightly
different functionality provided by *some* audio interfaces that
pertains to multistreaming, and then find that you've still left a lot
of users in the dark. The number of cycles you will lose by doing this
in software rather than trying to abstract the h/w capability will
probably be available to your users for no extra cost by the end of
your work.

Just my $0.01 ...

--p



-------------------------------------------------------
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 hw mixing with volume

[Ove Kaaven]

man, 08.03.2004 kl. 17.20 skrev Paul Davis:
> The kinds of features you seem to expect from hardware didn't exist in
> most devices 2 years ago. Its likely that features currently
> considered "experimental" in hardware right now (matrix mixing springs
> to mind) will become more common 2 years from now.

Sounds interesting.

> Does your manager think it wise to be writing software that is so tied
> into a particular model of what audio interfaces can do that it will
> be obsolete by the time processors run about 4 times as fast as they
> do now?

To the extent your assumptions are true: Yes. It's even pretty nearly a
part of the job description.

> People wrote game engines that did all this "multistream+backfill"
> stuff years before any cards provided hardware mixing, and they did
> most of it in software on CPU's that were 10-40 times slower than
> todays leading edge game-friendly processors. You are going to burn a
> lot of time trying to find common ways to access the slightly
> different functionality provided by *some* audio interfaces that
> pertains to multistreaming, and then find that you've still left a lot
> of users in the dark. The number of cycles you will lose by doing this
> in software rather than trying to abstract the h/w capability will
> probably be available to your users for no extra cost by the end of
> your work.

And by that time, games will be even more demanding than before, and
still want to use those cycles for itself rather than software sound
processing, so just sitting idle waiting for the ultimate
infinite-megahertz cpu, that can do everything in no time, gains nobody
anything... at least our business won't.

Nobody is asking you to like that, we don't even ask people to like us
or our business (generally the most we ask is to dislike it for the
right reasons), but working on more or less suboptimal designs is part
of the job, and no amount of argumentation is going to change that. Yes,
we try to avoid bad designs whenever we can, but that's often not
possible.




-------------------------------------------------------
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 hw mixing with volume

[Paul Davis]

>And by that time, games will be even more demanding than before, and
>still want to use those cycles for itself rather than software sound
>processing, so just sitting idle waiting for the ultimate
>infinite-megahertz cpu, that can do everything in no time, gains nobody
>anything... at least our business won't.

but don't you also want to be able to sell as many copies as possible
to as many satisfied customers as possible? if so, you have to pay
attention to whatever standards can be found for the domain at
hand. in this case, the AC97 codec spec (and its recent successor
whose name i forget) is about the most relevant thing i can think
of. AFAIK, AC97 etc. say nothing about the kinds of gain control and
mix routing that exist for multiple PCM streams. ergo, there is no
standard way to do this that will work across a significant fraction
of the installed and/or potential user base.

so, either ALSA can come up with such a thing, which might be
interesting but the manpower available to work on it is very limited,
or parties that have a vested interest in it can use an existing API
(SDL springs to mind, though i've never looked at it) or develop a new
one that provides a standard mechanism for doing wat you want.

i mean, even at the most basic level, the audio interface that is
built into my laptop motherboard (some intel nonsense) cannot do any
sample rate other than 48kHz! this is a high end laptop (HP Pavilion
zd7000, 3GHz processor, 1440x900 display, etc) ... think of the cycles
that will be spent *resampling* your audio independently of the mixing
step. this type of BS seems to be growing more and more common. if i
was in your position (specifically, if i have to assume that my user
base spent a (comparatively) lot of money on a graphics card, maybe
even paid for a 5.1 speaker setup, but are still using the
factory-provided audio interface, i would assume the absolute worst
capabilities for that interface that i could: single sample rate,
single PCM stream, no mixer.

and btw, i wasn't suggesting that you just "sit there waiting". my
point was that the time you might spend working on this could be spent
working on something else, and by the time you're done, CPU speed
increases will have done this particular task for you.

--p



-------------------------------------------------------
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 hw mixing with volume

[Takashi Iwai]

At Tue, 09 Mar 2004 09:26:56 -0500,
Paul Davis wrote:
> 
> >And by that time, games will be even more demanding than before, and
> >still want to use those cycles for itself rather than software sound
> >processing, so just sitting idle waiting for the ultimate
> >infinite-megahertz cpu, that can do everything in no time, gains nobody
> >anything... at least our business won't.
> 
> but don't you also want to be able to sell as many copies as possible
> to as many satisfied customers as possible? if so, you have to pay
> attention to whatever standards can be found for the domain at
> hand. in this case, the AC97 codec spec (and its recent successor
> whose name i forget) is about the most relevant thing i can think
> of. AFAIK, AC97 etc. say nothing about the kinds of gain control and
> mix routing that exist for multiple PCM streams. ergo, there is no
> standard way to do this that will work across a significant fraction
> of the installed and/or potential user base.

BTW, the USB audio is another headache.
the current ALSA PCM model isn't perfectly suitable for the devices
like USB audio.  (well, the current JACK implementation has the same
problem, too ;)

just an off-topic here, though...

> so, either ALSA can come up with such a thing, which might be
> interesting but the manpower available to work on it is very limited,
> or parties that have a vested interest in it can use an existing API
> (SDL springs to mind, though i've never looked at it) or develop a new
> one that provides a standard mechanism for doing wat you want.
> 
> i mean, even at the most basic level, the audio interface that is
> built into my laptop motherboard (some intel nonsense) cannot do any
> sample rate other than 48kHz! this is a high end laptop (HP Pavilion
> zd7000, 3GHz processor, 1440x900 display, etc) ... think of the cycles
> that will be spent *resampling* your audio independently of the mixing
> step. this type of BS seems to be growing more and more common. if i
> was in your position (specifically, if i have to assume that my user
> base spent a (comparatively) lot of money on a graphics card, maybe
> even paid for a 5.1 speaker setup, but are still using the
> factory-provided audio interface, i would assume the absolute worst
> capabilities for that interface that i could: single sample rate,
> single PCM stream, no mixer.
> 
> and btw, i wasn't suggesting that you just "sit there waiting". my
> point was that the time you might spend working on this could be spent
> working on something else, and by the time you're done, CPU speed
> increases will have done this particular task for you.

i guess that the special implementation for sb live! would be
relatively easy once when the API is defined.  it's nothing but a
reduced version of PCM streams, so the h/w control is already in the
driver.
the most difficult part is the definition of the (somehow) generic but
effective API.  the same is true for 3D audio API.

it'd be appreciated if app developers have a concrete wish list of API
design about these stuffs, or even better a proposal of the API.


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

USB audio devices

[Jaroslav Kysela]

On Tue, 9 Mar 2004, Takashi Iwai wrote:

> BTW, the USB audio is another headache. the current ALSA PCM model isn't
> perfectly suitable for the devices like USB audio.

Unfortunately I don't see a better model. We have already clear handshake,
but USB 1.1 devices, and maybe the Linux core USB code, are failing to
satisfy highly realtime needs, thus we need to manage the extra buffering
to avoid underflows for the DMA operations. I don't know much about USB
2.0, but I guess that 1.x compatibility issues brings another overhead to
this extension which makes it also unuseable when 1.x devices are
connected to same USB port.

I think that it's hardware design issue when the "extra delay" is counted, 
so we can hardly improve things.

						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: USB audio devices

[Clemens Ladisch]

Jaroslav Kysela wrote:

> On Tue, 9 Mar 2004, Takashi Iwai wrote:
>
> > BTW, the USB audio is another headache. the current ALSA PCM model isn't
> > perfectly suitable for the devices like USB audio.
>
> Unfortunately I don't see a better model.

Conceptually, USB devices have variable-sized periods.  The question
is whether we actually want to allow this in the API.  Probably not.

I have thought about forcing the period size to one ALSA frame (with
period_elapsed() calls at USB frame boundaries, like it's now).  In
theory, applications should be able to cope with this.

> I don't know much about USB 2.0,

Not too much differences for the driver.  The main difference is that
there are now 8000 microframes per second.  I have written a patch
(see below) and am about to test it.

> but I guess that 1.x compatibility issues brings another overhead
> to this extension which makes it also unuseable when 1.x devices
> are connected to same USB port.

There are some nasty contortions when a 1.x device is connected
through a 2.0 hub, but otherwise there is no overhead for 1.x devices
because logically (and electrically AFAIK) either the 2.0 or the 1.x
host controller device is connected to a specific port.


Regards,
Clemens

-- 
Index: alsa-kernel/usb/usbaudio.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/usb/usbaudio.c,v
retrieving revision 1.87
diff -u -r1.87 usbaudio.c
--- alsa-kernel/usb/usbaudio.c	8 Mar 2004 09:29:51 -0000	1.87
+++ alsa-kernel/usb/usbaudio.c	8 Mar 2004 09:48:09 -0000
@@ -104,6 +104,7 @@
  */

 #define MAX_PACKS	10
+#define MAX_PACKS_HS	(MAX_PACKS * 8)	/* in high speed mode */
 #define MAX_URBS	5	/* max. 20ms long packets */
 #define SYNC_URBS	2	/* always two urbs for sync */
 #define MIN_PACKS_URB	1	/* minimum 1 packet per urb */
@@ -165,6 +166,8 @@
 	unsigned int freqm;      /* momentary sampling rate in USB format, i.e. fs/1000 in Q10.14 */
 	unsigned int freqmax;    /* maximum sampling rate, used for buffer management */
 	unsigned int phase;      /* phase accumulator */
+	unsigned int phase_shift;	/* fractional bits of phase */
+	unsigned int phase_mask;	/* (1 << phase_shift) - 1 */
 	unsigned int maxpacksize;	/* max packet size in bytes */
 	unsigned int maxframesize;	/* max packet size in frames */
 	unsigned int curpacksize;	/* current packet size in bytes (for capture) */
@@ -250,7 +253,6 @@
 		cp[1] = subs->freqn >> 8;
 		cp[2] = subs->freqn >> 16;
 	}
-	urb->interval = 1;
 	return 0;
 }

@@ -301,7 +303,6 @@
 	spin_unlock_irqrestore(&subs->lock, flags);
 	urb->transfer_buffer = ctx->buf;
 	urb->transfer_buffer_length = offs;
-	urb->interval = 1;
 #if 0 // for check
 	if (! urb->bandwidth) {
 		int bustime;
@@ -390,7 +391,6 @@
 		urb->iso_frame_desc[i].length = 3;
 		urb->iso_frame_desc[i].offset = offs;
 	}
-	urb->interval = 1;
 	return 0;
 }

@@ -464,8 +464,8 @@
 		if (subs->fill_max)
 			counts = subs->maxframesize; /* fixed */
 		else {
-			subs->phase = (subs->phase & 0x3fff) + subs->freqm;
-			counts = subs->phase >> 14;
+			subs->phase = (subs->phase & subs->phase_mask) + subs->freqm;
+			counts = subs->phase >> subs->phase_shift;
 			if (counts > subs->maxframesize)
 				counts = subs->maxframesize;
 		}
@@ -515,7 +515,6 @@
 	spin_unlock_irqrestore(&subs->lock, flags);
 	urb->transfer_buffer_length = offs * stride;
 	ctx->transfer = offs;
-	urb->interval = 1;

 	return 0;
 }
@@ -822,15 +821,22 @@
 {
 	unsigned int maxsize, n, i;
 	int is_playback = subs->direction == SNDRV_PCM_STREAM_PLAYBACK;
-	unsigned int npacks[MAX_URBS], total_packs;
+	unsigned int npacks[MAX_URBS], urb_packs, total_packs;

 	/* calculate the frequency in 10.14 format */
 	subs->freqn = subs->freqm = get_usb_rate(rate);
 	subs->freqmax = subs->freqn + (subs->freqn >> 2); /* max. allowed frequency */
 	subs->phase = 0;
+	if (subs->dev->speed == USB_SPEED_HIGH) {
+		subs->phase_shift = 11;
+		subs->phase_mask = 0x07ff;
+	} else {
+		subs->phase_shift = 14;
+		subs->phase_mask = 0x3fff;
+	}

 	/* calculate the max. size of packet */
-	maxsize = ((subs->freqmax + 0x3fff) * (frame_bits >> 3)) >> 14;
+	maxsize = ((subs->freqmax + subs->phase_mask) * (frame_bits >> 3)) >> subs->phase_shift;
 	if (subs->maxpacksize && maxsize > subs->maxpacksize) {
 		//snd_printd(KERN_DEBUG "maxsize %d is greater than defined size %d\n",
 		//	   maxsize, subs->maxpacksize);
@@ -842,9 +848,14 @@
 	else
 		subs->curpacksize = maxsize;

+	if (subs->dev->speed == USB_SPEED_HIGH)
+		urb_packs = nrpacks * 8;
+	else
+		urb_packs = nrpacks;
+
 	/* allocate a temporary buffer for playback */
 	if (is_playback) {
-		subs->tmpbuf = kmalloc(maxsize * nrpacks, GFP_KERNEL);
+		subs->tmpbuf = kmalloc(maxsize * urb_packs, GFP_KERNEL);
 		if (! subs->tmpbuf) {
 			snd_printk(KERN_ERR "cannot malloc tmpbuf\n");
 			return -ENOMEM;
@@ -855,16 +866,16 @@
 	total_packs = (period_bytes + maxsize - 1) / maxsize;
 	if (total_packs < 2 * MIN_PACKS_URB)
 		total_packs = 2 * MIN_PACKS_URB;
-	subs->nurbs = (total_packs + nrpacks - 1) / nrpacks;
+	subs->nurbs = (total_packs + urb_packs - 1) / urb_packs;
 	if (subs->nurbs > MAX_URBS) {
 		/* too much... */
 		subs->nurbs = MAX_URBS;
-		total_packs = MAX_URBS * nrpacks;
+		total_packs = MAX_URBS * urb_packs;
 	}
 	n = total_packs;
 	for (i = 0; i < subs->nurbs; i++) {
-		npacks[i] = n > nrpacks ? nrpacks : n;
-		n -= nrpacks;
+		npacks[i] = n > urb_packs ? urb_packs : n;
+		n -= urb_packs;
 	}
 	if (subs->nurbs <= 1) {
 		/* too little - we need at least two packets
@@ -913,6 +924,7 @@
 		u->urb->pipe = subs->datapipe;
 		u->urb->transfer_flags = URB_ISO_ASAP;
 		u->urb->number_of_packets = u->packets;
+		u->urb->interval = 1;
 		u->urb->context = u;
 		u->urb->complete = snd_usb_complete_callback(snd_complete_urb);
 	}
@@ -935,6 +947,7 @@
 			u->urb->pipe = subs->syncpipe;
 			u->urb->transfer_flags = URB_ISO_ASAP;
 			u->urb->number_of_packets = u->packets;
+			u->urb->interval = subs->dev->speed == USB_SPEED_HIGH ? 8 : 1;
 			u->urb->context = u;
 			u->urb->complete = snd_usb_complete_callback(snd_complete_sync_urb);
 		}




-------------------------------------------------------
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: USB audio devices

[Jaroslav Kysela]

On Wed, 10 Mar 2004, Clemens Ladisch wrote:

> Jaroslav Kysela wrote:
> 
> > On Tue, 9 Mar 2004, Takashi Iwai wrote:
> >
> > > BTW, the USB audio is another headache. the current ALSA PCM model isn't
> > > perfectly suitable for the devices like USB audio.
> >
> > Unfortunately I don't see a better model.
> 
> Conceptually, USB devices have variable-sized periods.  The question
> is whether we actually want to allow this in the API.  Probably not.

What this does mean? I though that the period size is specified with time 
(1ms) for USB, isn't it? I think that we can describe this constraint 
with the refine algorithm.

						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: USB audio devices

[Takashi Iwai]

At Wed, 10 Mar 2004 10:08:26 +0100 (CET),
Jaroslav wrote:
> 
> On Wed, 10 Mar 2004, Clemens Ladisch wrote:
> 
> > Jaroslav Kysela wrote:
> > 
> > > On Tue, 9 Mar 2004, Takashi Iwai wrote:
> > >
> > > > BTW, the USB audio is another headache. the current ALSA PCM model isn't
> > > > perfectly suitable for the devices like USB audio.
> > >
> > > Unfortunately I don't see a better model.
> > 
> > Conceptually, USB devices have variable-sized periods.  The question
> > is whether we actually want to allow this in the API.  Probably not.
> 
> What this does mean? I though that the period size is specified with time 
> (1ms) for USB, isn't it? I think that we can describe this constraint 
> with the refine algorithm.

the period "time" is constant but the sample numbers in this period
varies from time to time because of tuncation to integer or due to
sync mode.  so far, we assume that the samples in a period is
constant.

we have some cases which we can't handle properly:

1) the period time is constant but the period size is variable
   e.g. USB-audio

2) the period size is constant but the period time is variable
   e.g. synchronization with another stream or clock source
        vari-speed stream

3) both period size and time are variable
   ???  not known


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: USB audio devices

[Karsten Wiese]

We can also vary the exact USB frame time.
With UHCI 1.1 USB Hosts there is the SOF Register. 
It is setable from 0 to 255, the default being 127.
Using this SOF-Register, we can set the actual USB Frame Rate from 
((12000 - 127) / 12000)ms to ((12000 + 128) / 12000)ms. That is about -/+ 1%:
More than enough to adjust the USB-Frame rate to let us get 44(44100) or 48
(48000) Sample Frames everyy USB Frame.
It really works here already with the us428: The trick is:
We first make the USB-Frame longer until we capture 1 Sample Frame more  45 
(for 44100). then the USB-Frame is shortened until we capture only 43 Sample 
Frames for one USB Frame. and so on. 
If we use a period size of multiples of 44 (for 44100) then :
- Latency is almost at its best (only 1/44 less than optimal.
- User Prog Scheduling Jitter is minimized.
- Alsas keeps constant Period size.

cheers,
Karsten




-------------------------------------------------------
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: USB audio devices

[Patrick Shirkey]

Karsten Wiese wrote:
> We can also vary the exact USB frame time.
> With UHCI 1.1 USB Hosts there is the SOF Register. 
> It is setable from 0 to 255, the default being 127.
> Using this SOF-Register, we can set the actual USB Frame Rate from 
> ((12000 - 127) / 12000)ms to ((12000 + 128) / 12000)ms. That is about -/+ 1%:
> More than enough to adjust the USB-Frame rate to let us get 44(44100) or 48
> (48000) Sample Frames everyy USB Frame.
> It really works here already with the us428: The trick is:
> We first make the USB-Frame longer until we capture 1 Sample Frame more  45 
> (for 44100). then the USB-Frame is shortened until we capture only 43 Sample 
> Frames for one USB Frame. and so on. 
> If we use a period size of multiples of 44 (for 44100) then :
> - Latency is almost at its best (only 1/44 less than optimal.
> - User Prog Scheduling Jitter is minimized.
> - Alsas keeps constant Period size.
> 

Hallaluhjah

Please please please make this standard for the usb audio driver.



-- 
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org/LAU/guide/ - The Linux Audio Users guide
Http://www.djcj.org/gigs/ - Gigs guide Korea
========================================


Apparently upon the beginning of the barrage, the donkey broke 
discipline and panicked, toppling the cart. At that point, the rockets 
disconnected from the timer, leaving them strewn around the street. 
Tethered to the now toppled cart, the donkey was unable to escape before 
the arrival of U.S. troops.

United Press International
Rockets on donkeys hit major Baghdad sites

By P. MITCHELL PROTHERO
Published 11/21/2003 11:13 AM



-------------------------------------------------------
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: USB audio devices

[Clemens Ladisch]

Karsten Wiese wrote:
> We can also vary the exact USB frame time.
> With UHCI 1.1 USB Hosts there is the SOF Register.
> ...
> It really works here already with the us428: The trick is:
> We first make the USB-Frame longer until we capture 1 Sample Frame more  45
> (for 44100). then the USB-Frame is shortened until we capture only 43 Sample
> Frames for one USB Frame. and so on.

Cool idea!

However, standard-compliant devices are supposed to base their timing
for feedback/feedforward information on the arrival of SOF packets.
Introducing jitter into the SOF timer may not be a good idea in every
case.

And this won't work if there is more than one audio device connected
to the same bus, or if the HC is OHCI or EHCI.


Regards,
Clemens




-------------------------------------------------------
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: USB audio devices

[Clemens Ladisch]

Jaroslav Kysela wrote:

> On Wed, 10 Mar 2004, Clemens Ladisch wrote:
>
> > Conceptually, USB devices have variable-sized periods.  The question
> > is whether we actually want to allow this in the API.  Probably not.
>
> What this does mean? I though that the period size is specified with time
> (1ms) for USB, isn't it? I think that we can describe this constraint
> with the refine algorithm.

One USB frame is 1 ms, but the number of samples per USB frame varies
if the sample rate isn't an integer multiple of 1000.  E.g., at
44100 Hz, each USB frame has 44 samples, with one out of ten having
45.

I don't know what happens when we constrain the period size to 1 ms,
which would be exactly 44.1 frames.  The period size in frames gets
rounded to an integer, doesn't it?


Regards,
Clemens




-------------------------------------------------------
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: USB audio devices

[Takashi Iwai]

At Wed, 10 Mar 2004 09:26:27 +0100 (MET),
Clemens Ladisch wrote:
> 
> > I don't know much about USB 2.0,
> 
> Not too much differences for the driver.  The main difference is that
> there are now 8000 microframes per second.  I have written a patch
> (see below) and am about to test it.

is there any "real" usb2-audio device available?


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: USB audio devices

[Clemens Ladisch]

Takashi Iwai wrote:
> Clemens Ladisch wrote:
> >
> > > I don't know much about USB 2.0,
> >
> > Not too much differences for the driver.  The main difference is that
> > there are now 8000 microframes per second.  I have written a patch
> > (see below) and am about to test it.
>
> is there any "real" usb2-audio device available?

I have (remote) access to a machine with an Audigy 2 NX, which can do
USB 2.0.  And there is the Ediroal UA-1000, which I would really like
to have access to. :-)


Regards,
Clemens




-------------------------------------------------------
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: USB audio devices

[Clemens Ladisch]

Clemens Ladisch wrote:

> Jaroslav Kysela wrote:
>
> > I don't know much about USB 2.0,
>
> Not too much differences for the driver.

Well, I should have read the specification before saying such things.
The format of synchronization information has changed, too; it's not
10.14 bits but 12.13 packed into 16.16 (4 bytes).


Regards,
Clemens




-------------------------------------------------------
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 hw mixing with volume

[Ove Kaaven]

tir, 09.03.2004 kl. 15.26 skrev Paul Davis:
> >And by that time, games will be even more demanding than before, and
> >still want to use those cycles for itself rather than software sound
> >processing, so just sitting idle waiting for the ultimate
> >infinite-megahertz cpu, that can do everything in no time, gains nobody
> >anything... at least our business won't.
> 
> but don't you also want to be able to sell as many copies as possible
> to as many satisfied customers as possible?

I suppose that's basically the idea. Customers want full support for
their hardware. Which includes HW mixing.

> if so, you have to pay
> attention to whatever standards can be found for the domain at
> hand. in this case, the AC97 codec spec (and its recent successor
> whose name i forget) is about the most relevant thing i can think
> of. AFAIK, AC97 etc. say nothing about the kinds of gain control and
> mix routing that exist for multiple PCM streams.

Yeah, we could consider AC97 to be a lowest common denominator. (That's
not to say it is, since very old sound cards won't be compliant.)

> ergo, there is no
> standard way to do this that will work across a significant fraction
> of the installed and/or potential user base.

Are you mocking ALSA's plugin interface, too? Is there no "standard way"
to play 22.050kHz streams using e.g. plughw? Or is plughw a design
mistake? It can't be extended to use the route/volume plugin to adjust
the volume of the stream in a "standard way", I suppose?

> so, either ALSA can come up with such a thing, which might be
> interesting but the manpower available to work on it is very limited,
> or parties that have a vested interest in it can use an existing API
> (SDL springs to mind, though i've never looked at it) or develop a new
> one that provides a standard mechanism for doing wat you want.

That's always going to be the case. It's Using Open Source In Business
101.

> i mean, even at the most basic level, the audio interface that is
> built into my laptop motherboard (some intel nonsense) cannot do any
> sample rate other than 48kHz! this is a high end laptop (HP Pavilion
> zd7000, 3GHz processor, 1440x900 display, etc) ... think of the cycles
> that will be spent *resampling* your audio independently of the mixing
> step.

Independently? No, our software mixing code resamples, adjusts volume,
and mixes the stream into the buffer in one step. That's one reason
we've decided not to use ALSA's plugin system, as they do it in several
steps (you'd have to run it through the rate plugin, the route/volume
plugin, and finally the dmix plugin). For best performance, we resample
on our own when the sound chip is locked to 48kHz (if we didn't, we
might end up letting each sound go through *two* resampling steps - one
from the sound effect's sample rate to the mixer stream's sample rate,
and another from the mixer stream's rate to the sound card's physical
rate if they don't match, therefore it's better to simply make the mixer
stream's rate match the sound card's, so that each sound effect is
resampled once and only once).

> this type of BS seems to be growing more and more common.

Perhaps they're thinking like you seem to, that the rise of CPU power
will make hardware features obsolete. "Hardware has limitations,
software don't." Same thing with winmodems. Why then do companies like
Creative churn out sound cards with ever more powerful hardware
features, if you're saying nobody should ever write code to take
advantage of those hardware features?

Since we're ranting anyway: It's a similar situation with 3D graphics
hardware, where the 3D cards get ever more powerful, even though the CPU
power is going up. And yet the OpenGL folks (at least those working on
DRI) say "it's not important for the app to know whether something is
done in hardware or not", which I have yet to make sense of given the
trend. It's obvious that the greatest in-game 3D on the planet could not
be done in smooth realtime on just a CPU without a GPU (particularly
when the CPU is also supposed to control enemy AI, make 3D environmental
effects on a 48kHz single-stream AC97 chip, communicate with other
players via a winmodem, and so on), so why shouldn't there be a feature
to tell that certain advanced 3D effects *could* be offloaded to
hardware without getting more CPU load?

>  if i
> was in your position (specifically, if i have to assume that my user
> base spent a (comparatively) lot of money on a graphics card, maybe
> even paid for a 5.1 speaker setup, but are still using the
> factory-provided audio interface, i would assume the absolute worst
> capabilities for that interface that i could: single sample rate,
> single PCM stream, no mixer.

Assumptions are seldom worth much. We're not going to assume anything
here. If the card has sufficient hardware features, we wish to use them
for what they're worth, since that's what they're there for. If it
doesn't have them, then we obviously fall back to the old software
mixing code that's been in our codebase forever. Is a customer who says
"I spent $500 on this new great sound card, but the sound is just as
lousy as before" a happy one? I think not.

> and btw, i wasn't suggesting that you just "sit there waiting". my
> point was that the time you might spend working on this could be spent
> working on something else, and by the time you're done, CPU speed
> increases will have done this particular task for you.

If ALSA provides the interface, it's just a matter of using it instead
of software mixing. There's no magic involved that's going to take
man-years to accomplish.




-------------------------------------------------------
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 hw mixing with volume

[Manuel Jander]

Hi,

On Tue, 2004-03-09 at 13:25, Ove Kaaven wrote:
> tir, 09.03.2004 kl. 15.26 skrev Paul Davis:
> > >And by that time, games will be even more demanding than before, and
> > >still want to use those cycles for itself rather than software sound
> > >processing, so just sitting idle waiting for the ultimate
> > >infinite-megahertz cpu, that can do everything in no time, gains nobody
> > >anything... at least our business won't.
> > 
> > but don't you also want to be able to sell as many copies as possible
> > to as many satisfied customers as possible?
> 
> I suppose that's basically the idea. Customers want full support for
> their hardware. Which includes HW mixing.

I agree.

> > if so, you have to pay
> > attention to whatever standards can be found for the domain at
> > hand. in this case, the AC97 codec spec (and its recent successor
> > whose name i forget) is about the most relevant thing i can think
> > of. AFAIK, AC97 etc. say nothing about the kinds of gain control and
> > mix routing that exist for multiple PCM streams.
> 
> Yeah, we could consider AC97 to be a lowest common denominator. (That's
> not to say it is, since very old sound cards won't be compliant.)

AC97 means that you have at least one PCM stream. Nothing more than
that. IMHO its pointless to say AC97 is a hardware capability. Its one
way to accomplish a task that is common to any audio device.

> > ergo, there is no
> > standard way to do this that will work across a significant fraction
> > of the installed and/or potential user base.
> 
> Are you mocking ALSA's plugin interface, too? Is there no "standard way"
> to play 22.050kHz streams using e.g. plughw? Or is plughw a design
> mistake? It can't be extended to use the route/volume plugin to adjust
> the volume of the stream in a "standard way", I suppose?

I think it would be interesting to apply several effects at once. But it
may be hard to come up with a clean design to accomplish that.

> > so, either ALSA can come up with such a thing, which might be
> > interesting but the manpower available to work on it is very limited,
> > or parties that have a vested interest in it can use an existing API
> > (SDL springs to mind, though i've never looked at it) or develop a new
> > one that provides a standard mechanism for doing wat you want.
> 
> That's always going to be the case. It's Using Open Source In Business
> 101.

AFAIK, OpenAL was developed for such purposes, but unfortunately its
development is stuck. The Linux and MAC ports don't support any hardware
features yet. BTW, i'm designing a control interface for ALSA for OpenAL
(the current aureal driver, to be commited to public CVS in a few days,
includes its first steps).

> > i mean, even at the most basic level, the audio interface that is
> > built into my laptop motherboard (some intel nonsense) cannot do any
> > sample rate other than 48kHz! this is a high end laptop (HP Pavilion
> > zd7000, 3GHz processor, 1440x900 display, etc) ... think of the cycles
> > that will be spent *resampling* your audio independently of the mixing
> > step.
> 
> Independently? No, our software mixing code resamples, adjusts volume,
> and mixes the stream into the buffer in one step. That's one reason
> we've decided not to use ALSA's plugin system, as they do it in several
> steps (you'd have to run it through the rate plugin, the route/volume
> plugin, and finally the dmix plugin). For best performance, we resample
> on our own when the sound chip is locked to 48kHz (if we didn't, we
> might end up letting each sound go through *two* resampling steps - one
> from the sound effect's sample rate to the mixer stream's sample rate,
> and another from the mixer stream's rate to the sound card's physical
> rate if they don't match, therefore it's better to simply make the mixer
> stream's rate match the sound card's, so that each sound effect is
> resampled once and only once).

I agree. IMHO thats the most efficient way. Thats the way OpenAL handles
such a case, but there is still a inconsistency, because the current
OpenAL linux port -should- not provide software fallbacks, but it does
anything in software (since there is still no hardware support), so it
looks like software fallback will be provided inside the driver (ALSA).
Since it can't (shouldn't) live in kernel context, i guess it would go
into alsa-lib (plugin perhaps ?).

> > this type of BS seems to be growing more and more common.
> 
> Perhaps they're thinking like you seem to, that the rise of CPU power
> will make hardware features obsolete. "Hardware has limitations,
> software don't." Same thing with winmodems. Why then do companies like
> Creative churn out sound cards with ever more powerful hardware
> features, if you're saying nobody should ever write code to take
> advantage of those hardware features?

I own a 4 year old soundcard, which provides 16 very high quality 3D
processor pipelines, and i still can't make use of it on any OS except
win98. That definitely sucks, and i'm still struggling to change that.

> Since we're ranting anyway: It's a similar situation with 3D graphics
> hardware, where the 3D cards get ever more powerful, even though the CPU
> power is going up. And yet the OpenGL folks (at least those working on
> DRI) say "it's not important for the app to know whether something is
> done in hardware or not", which I have yet to make sense of given the
> trend. It's obvious that the greatest in-game 3D on the planet could not
> be done in smooth realtime on just a CPU without a GPU (particularly
> when the CPU is also supposed to control enemy AI, make 3D environmental
> effects on a 48kHz single-stream AC97 chip, communicate with other
> players via a winmodem, and so on), so why shouldn't there be a feature
> to tell that certain advanced 3D effects *could* be offloaded to
> hardware without getting more CPU load?

Using the CPU for all is bullshit. I have not seen any Mega Computer
outperforming in software the render quality and speed of a Rendition
Verité or a S3 ViRGE. The may be faster but at very poor quality.
Software audio mixing sucks just the same. IMHO dedicated processors
rules, in MODEM's, GPU's and audio boards.

> >  if i
> > was in your position (specifically, if i have to assume that my user
> > base spent a (comparatively) lot of money on a graphics card, maybe
> > even paid for a 5.1 speaker setup, but are still using the
> > factory-provided audio interface, i would assume the absolute worst
> > capabilities for that interface that i could: single sample rate,
> > single PCM stream, no mixer.
> 
> Assumptions are seldom worth much. We're not going to assume anything
> here. If the card has sufficient hardware features, we wish to use them
> for what they're worth, since that's what they're there for. If it
> doesn't have them, then we obviously fall back to the old software
> mixing code that's been in our codebase forever. Is a customer who says
> "I spent $500 on this new great sound card, but the sound is just as
> lousy as before" a happy one? I think not.

I agree.

> > and btw, i wasn't suggesting that you just "sit there waiting". my
> > point was that the time you might spend working on this could be spent
> > working on something else, and by the time you're done, CPU speed
> > increases will have done this particular task for you.
> 
> If ALSA provides the interface, it's just a matter of using it instead
> of software mixing. There's no magic involved that's going to take
> man-years to accomplish.

Those specific interfaces don't exist yet, but the kcontrol interface
can be used easily for that purpose. Its just a matter of designing them
accordingly.

Best Regards

Manuel Jander




-------------------------------------------------------
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\x1470&alloc_id638&op=click

Re: PCM hw mixing with volume

[Giuliano Pochini]

On 09-Mar-2004 Ove Kaaven wrote:

> Independently? No, our software mixing code resamples, adjusts volume,
> and mixes the stream into the buffer in one step.

It should be more efficient than separate passes. It minimizes
memory i/o and some operation (multiply-add == volume-mix) can
be done natively in the vector unit.


> Since we're ranting anyway: It's a similar situation with 3D graphics
> hardware, where the 3D cards get ever more powerful, even though the CPU
> power is going up. [...]

No need to enter the philosophycal battlefield. The fact it there is
no ALSA support for this yet. Thus, you can just await for it, or use
another mixer library, or help ALSA developers to write it.
Please start writing what the API should provide. My experience about
game development is quite obsolete and I can't help much, but you
should have a better idea about how the API should look like or, at
least, what minimal/preferred/dreamed features it should have.


--
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 hw mixing with volume

[Ove Kaaven]

ons, 10.03.2004 kl. 10.46 skrev Giuliano Pochini:
> On 09-Mar-2004 Ove Kaaven wrote:
> > Since we're ranting anyway: It's a similar situation with 3D graphics
> > hardware, where the 3D cards get ever more powerful, even though the CPU
> > power is going up. [...]
> 
> No need to enter the philosophycal battlefield.

Oh, I wasn't planning on it. I didn't say that to make an argument or
anything, just because "we're ranting anyway". Consider it venting, or
whatever, I'm not trying to persuade you, just make it clear that I have
an opinion which it's not worth Paul Davis's time to try to change. I'm
not trying to push that opinion on him or anyone else, just make it
clear that they shouldn't try to push theirs on me either, and then we
can get along together, agreeing that we disagree.

> The fact it there is
> no ALSA support for this yet. Thus, you can just await for it, or use
> another mixer library, or help ALSA developers to write it.

That point has already been made, and agreed upon. And not really what
we were debating, either.

> Please start writing what the API should provide.

Well, the requirements that raised this thread should be fairly clear.
For example,

ALTERNATIVE 1

snd_pcm_set_volume(snd_pcm_t* pcm, int volume)

and

snd_pcm_set_pan(snd_pcm_t* pcm, int pan)

using whatever value range makes the most sense, and perhaps some query
on whether these controls are available from the pcm info. It's
acceptable to have to explicitly ask for these controls using hw_params.
The plug plugin could insert the route/volume plugin if these controls
are asked for.

ALTERNATIVE 2

snd_pcm_set_volume(snd_pcm_t* pcm, int vol_left, int vol_right)

but I don't expect this to be useful, since there are probably some
oddball devices out there that aren't able to control left and right
volume independently like this.

ALTERNATIVE 3

Let each PCM channel have its own mixer control, like the EMU10K1
currently do. That is, use snd_pcm_info_get_subdevice() to get the
index, then look up a volume control with a well-known name and the
given index using the snd_ctl API to control the volume of that PCM
stream. The name and semantics of that mixer control would have to be
standardized and be the same on all devices that are capable of this
feature.

Whatever way is chosen, it's simple enough to work with.

But if we get into the realm of spatial sound, it can get trickier, of
course. I might suggest to create a new snd_pcm_fx_params_t or
something, which can be loaded into a PCM stream to change the volume,
pan, or other effect. The available effects should depend on which was
requested in hw_params. Specifically, the following effects would be
desirable:

* Volume
* Pan (not available if 3D sound is requested)
* Frequency (can be used for software-calculated doppler shift, or for
"wavetable synthesis"-like purposes)
* 3D position (relative to listener)
* Velocity (for hardware-calculated doppler shift)
* Cone inside/outside angles, direction, outside volume
* Min/max distance (wherever the sound is heard)

There are also settings that can be considered "global" for all sounds
in the game, but I'm not sure how they could really be considered such
using the PCM API, so it's acceptable to have to go through every PCM
stream and update the parameters of each one, if that's easier to
implement. If not, there must be a way to attach each 3D-aware PCM
stream to some kind of master structure which can hold these parameters.
This master can be a designated PCM stream with special hw_params.
Global settings include:

* 3D position, orientation (forward and upward directions), and velocity
of listener, to allow streams to use absolute, not relative,
coordinates, if they want to
* Distance, rolloff, and doppler factors (I don't remember the exact
semantics of these, but can look it up)

These will be required anyway for full HW-accelerated OpenAL support, of
course.

The API should also be designed to allow for further parametrized
effects to be applied to a particular stream, for example reverb
effects. For what it's worth, DirectSound has currently defined Gargle,
Chorus, Flanger, Echo, Distortion, Compressor, and a couple of Reverb
types...




-------------------------------------------------------
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 hw mixing with volume

[Ove Kaaven]

ons, 10.03.2004 kl. 15.16 skrev Ove Kaaven:
> * Volume
> * Pan (not available if 3D sound is requested)
> * Frequency (can be used for software-calculated doppler shift, or for
> "wavetable synthesis"-like purposes)
> * 3D position (relative to listener)
> * Velocity (for hardware-calculated doppler shift)
> * Cone inside/outside angles, direction, outside volume
> * Min/max distance (wherever the sound is heard)

Correction: Min distance is where the sound does not get any louder if
you get closer. Max distance is where the sound does not get any softer
if you get further away. Whether the sound is heard or not when over max
distance is optional, and should also be a parameter if min/max distance
is.

In any case, most of this can all be handled by software. The only stuff
the hardware really need is the volume, frequency, direction to sound
source, and any additional effects (such as reverb). Application
software can deal with the rest.




-------------------------------------------------------
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 hw mixing with volume

[Paul Davis]

>In any case, most of this can all be handled by software. The only stuff
>the hardware really need is the volume, frequency, direction to sound
>source, and any additional effects (such as reverb). Application
>software can deal with the rest.

i can certainly see the utility of such an API. however, i don't think
it should be part of the PCM API. these things don't really relate to
the basic concepts of handing a PCM-encoded stream of audio data to a
device, they represent much higher level concepts. a different API
would allow a much cleaner implementation and less complications for
developers. 

it would also leave the PCM API clean and its implementation free of
things that have no role to play in software that would never use the
hardware support even if it was there (i.e. music applications). 

i don't know what to call it, but perhaps something more like
snd_audio_*() would be more appropriate.

--p


-------------------------------------------------------
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 hw mixing with volume

[Takashi Iwai]

At Wed, 10 Mar 2004 15:16:34 +0100,
Ove Kaaven wrote:
> 
> > Please start writing what the API should provide.
> 
> Well, the requirements that raised this thread should be fairly clear.
> For example,
> 
> ALTERNATIVE 1
> 
> snd_pcm_set_volume(snd_pcm_t* pcm, int volume)
> 
> and
> 
> snd_pcm_set_pan(snd_pcm_t* pcm, int pan)

it'd be cleaner to separate these features from the existing snd_pcm
stuffs.  i.e. i'd like to see rather another class, with simplified
parameter setting and extended features.

> using whatever value range makes the most sense, and perhaps some query
> on whether these controls are available from the pcm info. It's
> acceptable to have to explicitly ask for these controls using hw_params.

hw_params is not a good candidate because it's a setup parameter at
the initialization but not applied to the running streams.

so, we need another record which is applicable dynamically during the
stream is running.

> The plug plugin could insert the route/volume plugin if these controls
> are asked for.

agreed.  the plugin solution sounds nice.

> ALTERNATIVE 2
> 
> snd_pcm_set_volume(snd_pcm_t* pcm, int vol_left, int vol_right)
> 
> but I don't expect this to be useful, since there are probably some
> oddball devices out there that aren't able to control left and right
> volume independently like this.

again plugin in such a case?

> ALTERNATIVE 3
> 
> Let each PCM channel have its own mixer control, like the EMU10K1
> currently do. That is, use snd_pcm_info_get_subdevice() to get the
> index, then look up a volume control with a well-known name and the
> given index using the snd_ctl API to control the volume of that PCM
> stream. The name and semantics of that mixer control would have to be
> standardized and be the same on all devices that are capable of this
> feature.

such an implementation detail will be anyway hidden in the library,
and shouldn't appear in the API itself.

> Whatever way is chosen, it's simple enough to work with.
> 
> But if we get into the realm of spatial sound, it can get trickier, of
> course. I might suggest to create a new snd_pcm_fx_params_t or
> something, which can be loaded into a PCM stream to change the volume,
> pan, or other effect. The available effects should depend on which was
> requested in hw_params. Specifically, the following effects would be
> desirable:
> 
> * Volume
> * Pan (not available if 3D sound is requested)
> * Frequency (can be used for software-calculated doppler shift, or for
> "wavetable synthesis"-like purposes)
> * 3D position (relative to listener)
> * Velocity (for hardware-calculated doppler shift)
> * Cone inside/outside angles, direction, outside volume
> * Min/max distance (wherever the sound is heard)

hmm, the question is how abstracted the ALSA API should be.
we have the openAL layer on the ALSA hw API.
so, the lower implementation isn't necessarily too generalized.

> There are also settings that can be considered "global" for all sounds
> in the game, but I'm not sure how they could really be considered such
> using the PCM API, so it's acceptable to have to go through every PCM
> stream and update the parameters of each one, if that's easier to
> implement. If not, there must be a way to attach each 3D-aware PCM
> stream to some kind of master structure which can hold these parameters.
> This master can be a designated PCM stream with special hw_params.
> Global settings include:
> 
> * 3D position, orientation (forward and upward directions), and velocity
> of listener, to allow streams to use absolute, not relative,
> coordinates, if they want to
> * Distance, rolloff, and doppler factors (I don't remember the exact
> semantics of these, but can look it up)
> 
> These will be required anyway for full HW-accelerated OpenAL support, of
> course.
> 
> The API should also be designed to allow for further parametrized
> effects to be applied to a particular stream, for example reverb
> effects. For what it's worth, DirectSound has currently defined Gargle,
> Chorus, Flanger, Echo, Distortion, Compressor, and a couple of Reverb
> types...

this reminds me the use of LADSPA plugins.  if the samples are handled
in float internally, we can use LADSPA plugins quite easily.
the calculation of float is cheap nowadays, the only cost is
conversion between different types.


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 hw mixing with volume

[Ove Kaaven]

ons, 10.03.2004 kl. 16.08 skrev Takashi Iwai:
> At Wed, 10 Mar 2004 15:16:34 +0100,
> Ove Kaaven wrote:
> > 
> > > Please start writing what the API should provide.
> > 
> > Well, the requirements that raised this thread should be fairly clear.
> > For example,
> > 
> > ALTERNATIVE 1
> > 
> > snd_pcm_set_volume(snd_pcm_t* pcm, int volume)
> > 
> > and
> > 
> > snd_pcm_set_pan(snd_pcm_t* pcm, int pan)
> 
> it'd be cleaner to separate these features from the existing snd_pcm
> stuffs.  i.e. i'd like to see rather another class, with simplified
> parameter setting and extended features.

Yeah, I suggested doing that with a snd_pcm_fx_params_t. But any way is
fine with me.

> > using whatever value range makes the most sense, and perhaps some query
> > on whether these controls are available from the pcm info. It's
> > acceptable to have to explicitly ask for these controls using hw_params.
> 
> hw_params is not a good candidate because it's a setup parameter at
> the initialization but not applied to the running streams.

Perhaps you misunderstood. I meant that hw_params is used in its setup
role to request such controls, not to use them. For example, if some
goon does this:

snd_pcm_hw_params_any(pcm, hw_params);
...set sample rate and format...
snd_pcm_hw_params(pcm, hw_params);
snd_pcm_prepare(pcm);
snd_pcm_set_volume(pcm, 100);
snd_pcm_set_pan(pcm, -10);

then ALSA would return errors or even assertion failures. But if this
was done:

snd_pcm_hw_params_any(pcm, hw_params);
...set sample rate and format...
snd_pcm_hw_set_controls(pcm, hw_params,
  SND_PCM_VOLUME_CONTROL | SND_PCM_PAN_CONTROL);
snd_pcm_hw_params(pcm, hw_params);
snd_pcm_prepare(pcm);
snd_pcm_set_volume(pcm, 100);
snd_pcm_set_pan(pcm, -10);

then the code would succeed. And then the "plug" plugin would then also
know in advance that it needs to pull in the route/volume plugin if the
hardware can't do it, while checking hw_params, same way I'd expect it
to pull in the rate plugin if the hw_params requests an unsupported
sample rate.

> > ALTERNATIVE 2
> > 
> > snd_pcm_set_volume(snd_pcm_t* pcm, int vol_left, int vol_right)
> > 
> > but I don't expect this to be useful, since there are probably some
> > oddball devices out there that aren't able to control left and right
> > volume independently like this.
> 
> again plugin in such a case?

Sure, for the general case, but our code probably won't use it as we
prefer to fall back to our own integrated software mixing code if
insufficient hardware capabilities are available for the purpose of the
stream. I'd expect volume/pan to be more flexible and widely supported
in hardware than left/right volume. The latter can easily be derived
from the former, after all, and perhaps some hardware might have only a
single volume and no pan (in which case it should be possible to use
that single volume without panning, whenever the stream doesn't need a
pan control).

> > ALTERNATIVE 3
> > 
> > Let each PCM channel have its own mixer control, like the EMU10K1
> > currently do. That is, use snd_pcm_info_get_subdevice() to get the
> > index, then look up a volume control with a well-known name and the
> > given index using the snd_ctl API to control the volume of that PCM
> > stream. The name and semantics of that mixer control would have to be
> > standardized and be the same on all devices that are capable of this
> > feature.
> 
> such an implementation detail will be anyway hidden in the library,
> and shouldn't appear in the API itself.

Perhaps, but the "well-known name" trick is already used for "PCM
Volume", so I didn't think this would be too different.

> > Whatever way is chosen, it's simple enough to work with.
> > 
> > But if we get into the realm of spatial sound, it can get trickier, of
> > course. I might suggest to create a new snd_pcm_fx_params_t or
> > something, which can be loaded into a PCM stream to change the volume,
> > pan, or other effect. The available effects should depend on which was
> > requested in hw_params. Specifically, the following effects would be
> > desirable:
> > 
> > * Volume
> > * Pan (not available if 3D sound is requested)
> > * Frequency (can be used for software-calculated doppler shift, or for
> > "wavetable synthesis"-like purposes)
> > * 3D position (relative to listener)
> > * Velocity (for hardware-calculated doppler shift)
> > * Cone inside/outside angles, direction, outside volume
> > * Min/max distance (wherever the sound is heard)
> 
> hmm, the question is how abstracted the ALSA API should be.
> we have the openAL layer on the ALSA hw API.
> so, the lower implementation isn't necessarily too generalized.

That's fine. It's possible we'd just end up writing a sound backend on
top of OpenAL eventually anyway, if OpenAL ever gets a more viable API
than the useless one it's currently sporting. I think our CTO has been
trying to fund people such as Ryan Gordon to redesign OpenAL. But
barring that, we should be able to adapt our own code to use any
features ALSA exposes, and just fall back to basics (which may mean
lower sound quality) when those features do not appear to be available
in any way.

> > The API should also be designed to allow for further parametrized
> > effects to be applied to a particular stream, for example reverb
> > effects. For what it's worth, DirectSound has currently defined Gargle,
> > Chorus, Flanger, Echo, Distortion, Compressor, and a couple of Reverb
> > types...
> 
> this reminds me the use of LADSPA plugins.  if the samples are handled
> in float internally, we can use LADSPA plugins quite easily.
> the calculation of float is cheap nowadays, the only cost is
> conversion between different types.

I guess. But there should be a way to let the sound card's DSP handle
some of those effects, if it can, rather than the CPU.




-------------------------------------------------------
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 hw mixing with volume

[Giuliano Pochini]

On 10-Mar-2004 Ove Kaaven wrote:

> Well, the requirements that raised this thread should be fairly clear.
> For example,
>
> ALTERNATIVE 1
>
> snd_pcm_set_volume(snd_pcm_t* pcm, int volume)
>
> and
>
> snd_pcm_set_pan(snd_pcm_t* pcm, int pan)
>
> using whatever value range makes the most sense, and perhaps some query
> on whether these controls are available from the pcm info. It's
> acceptable to have to explicitly ask for these controls using hw_params.
> The plug plugin could insert the route/volume plugin if these controls
> are asked for.

Uhm... I think first of all we need a way to know how many
virtual channels are available (hw and sw) and a function to
allocate some of them. The app may choose to use less channels
than it wishes in order to not fall back to software mixing.
set_volume() should be something more generic. Think about 5.1 .

Also, the API should lay above the PCM API because, if the
card hasn't the required capabilities, that layer will emulate
it using the PCM API. Also, in some cases (eg. the Echoaudio
Mia and probably hdsp), that mixing feature is already
supported by the driver through the normal PCM and control APIs.


> ALTERNATIVE 2
>
> snd_pcm_set_volume(snd_pcm_t* pcm, int vol_left, int vol_right)
>
> but I don't expect this to be useful, since there are probably some
> oddball devices out there that aren't able to control left and right
> volume independently like this.

And there are some cards which haven't a pan control, but only l/r
volumes.

There also is another important question: What is the unit used
to set the gain ?  Decibel is probably the right choice, but
the control API provides no way to translate the dB scale to the
scale used by the hardware.


> ALTERNATIVE 3
>
> Let each PCM channel have its own mixer control, like the EMU10K1
> currently do. That is, use snd_pcm_info_get_subdevice() to get the
> index, then look up a volume control with a well-known name and the
> given index using the snd_ctl API to control the volume of that PCM
> stream. The name and semantics of that mixer control would have to be
> standardized and be the same on all devices that are capable of this
> feature.

IMHO, it's not robust enough.


> Whatever way is chosen, it's simple enough to work with.
>
> But if we get into the realm of spatial sound, it can get trickier, of
> course. I might suggest to create a new snd_pcm_fx_params_t or
> something, which can be loaded into a PCM stream to change the volume,
> pan, or other effect. The available effects should depend on which was
> requested in hw_params. Specifically, the following effects would be
> desirable:
>
> * Volume
> * Pan (not available if 3D sound is requested)
> * Frequency (can be used for software-calculated doppler shift, or for
> "wavetable synthesis"-like purposes)
> * 3D position (relative to listener)
> * Velocity (for hardware-calculated doppler shift)
> * Cone inside/outside angles, direction, outside volume
> * Min/max distance (wherever the sound is heard)

And all the above must not be static. You may need to change
them while the sound is playing.


> The API should also be designed to allow for further parametrized
> effects to be applied to a particular stream, for example reverb
> effects. For what it's worth, DirectSound has currently defined Gargle,
> Chorus, Flanger, Echo, Distortion, Compressor, and a couple of Reverb
> types...

We can define a small set of standard effects, or we can do something
like the control API.


--
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 hw mixing with volume

[Ove Kaaven]

ons, 10.03.2004 kl. 16.55 skrev Giuliano Pochini:
> Uhm... I think first of all we need a way to know how many
> virtual channels are available (hw and sw)

For the EMU10K1, snd_pcm_info_get_subdevices_count() and
snd_pcm_info_get_subdevices_avail() works for me. But I suppose you're
right that this isn't a good abstraction.

> and a function to
> allocate some of them.

snd_pcm_open works for me for now... you mean reserve, perhaps?

>  The app may choose to use less channels
> than it wishes in order to not fall back to software mixing.
> set_volume() should be something more generic. Think about 5.1 .

I think 3D position controls or pan controls would be more appropriate
than a more flexible volume control. Or perhaps the stream might just be
6-channel in the first place...

> Also, the API should lay above the PCM API because, if the
> card hasn't the required capabilities, that layer will emulate
> it using the PCM API. Also, in some cases (eg. the Echoaudio
> Mia and probably hdsp), that mixing feature is already
> supported by the driver through the normal PCM and control APIs.

Good point, but I wonder how 3D effects could be applied to sounds
loaded into the card's onboard memory (via the suggested wavetable API).
Perhaps that won't be a very important feature though.

> > ALTERNATIVE 2
> >
> > snd_pcm_set_volume(snd_pcm_t* pcm, int vol_left, int vol_right)
> >
> > but I don't expect this to be useful, since there are probably some
> > oddball devices out there that aren't able to control left and right
> > volume independently like this.
> 
> And there are some cards which haven't a pan control, but only l/r
> volumes.

The l/r volume can easily be calculated from the volume and pan. That
doesn't make it less useful to make the API express it in terms of
vol/pan for the benefit of the hardware that don't use l/r volume.

> There also is another important question: What is the unit used
> to set the gain ?  Decibel is probably the right choice, but
> the control API provides no way to translate the dB scale to the
> scale used by the hardware.

I don't have a preference, but it probably should be addressed.

> > * Volume
> > * Pan (not available if 3D sound is requested)
> > * Frequency (can be used for software-calculated doppler shift, or for
> > "wavetable synthesis"-like purposes)
> > * 3D position (relative to listener)
> > * Velocity (for hardware-calculated doppler shift)
> > * Cone inside/outside angles, direction, outside volume
> > * Min/max distance (wherever the sound is heard)
> 
> And all the above must not be static. You may need to change
> them while the sound is playing.

Exactly.

> > The API should also be designed to allow for further parametrized
> > effects to be applied to a particular stream, for example reverb
> > effects. For what it's worth, DirectSound has currently defined Gargle,
> > Chorus, Flanger, Echo, Distortion, Compressor, and a couple of Reverb
> > types...
> 
> We can define a small set of standard effects, or we can do something
> like the control API.

As far as I'm concerned, as long as the API can do what I need, it
doesn't matter much what it looks like. DirectSound does allow
individual drivers to implement custom device-specific effects, but I
don't expect to really want that. Standard effects are good enough.




-------------------------------------------------------
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 hw mixing with volume

[Giuliano Pochini]

On 10-Mar-2004 Ove Kaaven wrote:

>> Uhm... I think first of all we need a way to know how many
>> virtual channels are available (hw and sw)
>
> For the EMU10K1, snd_pcm_info_get_subdevices_count() and
> snd_pcm_info_get_subdevices_avail() works for me. But I suppose you're
> right that this isn't a good abstraction.

It isn't good because the app wants a virtually unlimited
number of channels. I was thinking of something like this:

sndhandler=PrepareToPlay(sound);
SetVolume(sndhandler, -10);
SetPan(sndhandler, 0);
or SetPosition(sndhandler, x, y, z);
SetEffect(sndhandler, foo, bar);
Start(sndhandler);

The application shouldn't have to take care of the actual
number of virtual channels the card provides other than at
initialization, eg.:

AllocSfx("hw:0,0,2", 8); /* alloc 8 vchannels starting from subdev 2 */

Then Start() will play the sound using the allocated channels
in a LRU way of something similar.


>> set_volume() should be something more generic. Think about 5.1 .
>
> I think 3D position controls or pan controls would be more appropriate
> than a more flexible volume control. Or perhaps the stream might just be
> 6-channel in the first place...

It should be possible to mix them, SFX and background music.


>> Also, the API should lay above the PCM API because, if the
>> card hasn't the required capabilities, that layer will emulate
>> it using the PCM API. Also, in some cases (eg. the Echoaudio
>> Mia and probably hdsp), that mixing feature is already
>> supported by the driver through the normal PCM and control APIs.
>
> Good point, but I wonder how 3D effects could be applied to sounds
> loaded into the card's onboard memory (via the suggested wavetable API).
> Perhaps that won't be a very important feature though.

PrepareToPlay() loads the sample and Start() plays it. It's pretty
indipendent on how the sound will be actually played (through the
PCM API of the sequencer API or whatever). As you just reminded me
some cards have onboard memory that holds MIDI instruments. It can
be used for generic sound effects as well.


>> We can define a small set of standard effects, or we can do something
>> like the control API.
>
> As far as I'm concerned, as long as the API can do what I need, it
> doesn't matter much what it looks like. DirectSound does allow
> individual drivers to implement custom device-specific effects, but I
> don't expect to really want that. Standard effects are good enough.

Stardard effects are simple, but a more generic interface is
expandable. It's like OSS control interface vs ALSA control interface.


--
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 hw mixing with volume

[Takashi Iwai]

At Wed, 10 Mar 2004 16:55:05 +0100 (CET),
Giuliano Pochini wrote:
> 
> There also is another important question: What is the unit used
> to set the gain ?  Decibel is probably the right choice, but
> the control API provides no way to translate the dB scale to the
> scale used by the hardware.

dB extension is now under consideration, likely using an external
database, not built in the driver.

definitely we should have the controls in dB unit in future.


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 hw mixing with volume

[James Courtier-Dutton]

Ove Kaaven wrote:
> 
> 
> Well, the requirements that raised this thread should be fairly clear.
> For example,
> 
> ALTERNATIVE 1
> 
> snd_pcm_set_volume(snd_pcm_t* pcm, int volume)
> 
> and
> 
> snd_pcm_set_pan(snd_pcm_t* pcm, int pan)
> 
> using whatever value range makes the most sense, and perhaps some query
> on whether these controls are available from the pcm info. It's
> acceptable to have to explicitly ask for these controls using hw_params.
> The plug plugin could insert the route/volume plugin if these controls
> are asked for.
> 
> ALTERNATIVE 2
> 
> snd_pcm_set_volume(snd_pcm_t* pcm, int vol_left, int vol_right)
> 
> but I don't expect this to be useful, since there are probably some
> oddball devices out there that aren't able to control left and right
> volume independently like this.
> 
> ALTERNATIVE 3
> 
> Let each PCM channel have its own mixer control, like the EMU10K1
> currently do. That is, use snd_pcm_info_get_subdevice() to get the
> index, then look up a volume control with a well-known name and the
> given index using the snd_ctl API to control the volume of that PCM
> stream. The name and semantics of that mixer control would have to be
> standardized and be the same on all devices that are capable of this
> feature.
> 

What about 7.1 surround sound channels. All your suggestions only assume 
2 PCM channels.

Although it might seem nice to add this to alsa, it is not exactly a 
difficult task for the application to do itself.

I suggested exactly what you suggested some time ago (see alsa-devel 
archives), but recently I have realised that there is little or no point.
The application will contain a user interface control for the volume, so 
one might as well adjust the volume in software as well. It is not even 
very CPU intensive.

Cheers
James


-------------------------------------------------------
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 hw mixing with volume

[Manuel Jander]

Hi,


> What about 7.1 surround sound channels. All your suggestions only assume 
> 2 PCM channels.

Lets clarify something: A 3D stream is one mono stream, that is split
into all the necesary channels with the corresponding processing for
whatever amount of speaker / headphones you have, to get the single
audio channel spatialized. If we are talking about 5.1, 7.1 or 69.2,
that fact should be irrelevant for the API. The particular driver must
take care to make the audio stream sound like if it comes from the right
or left. Maybe the user should just tell ALSA what speaker setup is
being used, but the applications themself should not need to care about.

If we use 3D coordinates, the panning parameter would not be needed by
the way. All we need is a set of 3D coordinates relative to the
listener. Passing that info to the driver, it can set panning, HRTF
filters, Delay lines, or whatever it provides for that purpose.

Best Regards

Manuel Jander



-------------------------------------------------------
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

snd_intel8x0 fails after ACPI sleep

[gte654n]

I have a Fujitsu E7110 laptop with a builtin audio card.  This is what lspci 
reports... 
 
00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio (rev 
02) 
        Subsystem: Citicorp TTI: Unknown device 1177 
        Flags: bus master, medium devsel, latency 0, IRQ 11 
        I/O ports at 1000 [size=256] 
        I/O ports at 1880 [size=64] 
 
I am running 2.6.4-rc2 kernel, and I have been trying to get ACPI S3 (suspend 
to ram) to wake up correctly.  One of the problems that I am encountering is 
that with the sound modules loaded (I have always had success with 
snd_intel8x0 on the same hardware) coming back from sleep freezes my laptop 
hard.  If I rmmod *all* the sound-related modules before going to sleep, the 
laptop resumes without a hitch.  However, if I attempt to modprobe 
snd_intel8x0 after resume, I get a hard freeze again.  I cannot recover any 
debug output, because the end of /var/log/messages is garbled on reboot. 
 
I have looked on ALSA and ACPI mailing lists and have not been able to find a 
satisfactory answer to this.  It appears some people can reinsert the intel 
driver after resume, and they get their audio back.  I have no such luck.   
 
Could you please provide some tips on how I can help address this problem?  
For instance, what other information about my setup should I post.  Is there 
some documentation on audio power management under ACPI that I am overlooking?  
 
Thank you very much,  
 
Ilya 
 



-------------------------------------------------------
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\x1470&alloc_id638&op=click

Re: snd_intel8x0 fails after ACPI sleep

[Christoph Lukas]

Hi,

> I have a Fujitsu E7110 laptop with a builtin audio card.  This is what lspci 
> reports... 
>  
> 00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio (rev 
> 02) 
>         Subsystem: Citicorp TTI: Unknown device 1177 
>         Flags: bus master, medium devsel, latency 0, IRQ 11 
>         I/O ports at 1000 [size=256] 
>         I/O ports at 1880 [size=64] 
>  
> I am running 2.6.4-rc2 kernel, and I have been trying to get ACPI S3 (suspend 
> to ram) to wake up correctly.  One of the problems that I am encountering is 
> that with the sound modules loaded (I have always had success with 
> snd_intel8x0 on the same hardware) coming back from sleep freezes my laptop 
> hard.  If I rmmod *all* the sound-related modules before going to sleep, the 
> laptop resumes without a hitch.  However, if I attempt to modprobe 
> snd_intel8x0 after resume, I get a hard freeze again.  I cannot recover any 
> debug output, because the end of /var/log/messages is garbled on reboot. 

I have nearly the same behaviour here with a Dell D800 with the following sound card:

00:1f.5 Multimedia audio controller: Intel Corp.: Unknown device 24c5 (rev 01)
        Subsystem: Dell Computer Corporation: Unknown device 014e
        Flags: bus master, medium devsel, latency 0, IRQ 11
        I/O ports at b800 [size=256]
        I/O ports at bc40 [size=64]
        Memory at f4fff800 (32-bit, non-prefetchable) [size=512]
        Memory at f4fff400 (32-bit, non-prefetchable) [size=256]
        Capabilities: [50] Power Management version 2

If I unload usb, network and sound modules before entering S3 I can
resume successfully. 

Reloading the sound modules after resume the behaviour differs depending
on the order I load the modules in.

If I modprobe the snd modules _after_ usb or network modules the system
freezes. 
If I modprobe the snd modules _before_ the others I get the following
messages in the syslog:

Mar 13 18:54:25 beja kernel: PCI: Setting latency timer of device
0000:00:1f.5 to 64
Mar 13 18:54:25 beja kernel: ALSA
/usr/src/modules/alsa-driver/kbuild/../pci/intel8x0.c:1969: AC'97 warm
reset still in progress? [0xffffffff]
Mar 13 18:54:25 beja kernel: Intel ICH: probe of 0000:00:1f.5 failed
with error -5

Is this problem hardware specific or does the alsa system not support
ACPI powermanagement?

I would really like helping to get this to work as this is the only
problem preventing me from using S3. 

I could supply more information if necessary.

Thanks for any hints,
Christoph



-------------------------------------------------------
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 hw mixing with volume

[Manuel Jander]

Hi Ove,

On Wed, 2004-03-10 at 10:16, Ove Kaaven wrote:
> > Please start writing what the API should provide.
> 
> Well, the requirements that raised this thread should be fairly clear.
> For example,
> 
> ALTERNATIVE 1
> 
> snd_pcm_set_volume(snd_pcm_t* pcm, int volume)
> 
> and
> 
> snd_pcm_set_pan(snd_pcm_t* pcm, int pan)
> 
> using whatever value range makes the most sense, and perhaps some query
> on whether these controls are available from the pcm info. It's
> acceptable to have to explicitly ask for these controls using hw_params.
> The plug plugin could insert the route/volume plugin if these controls
> are asked for.

I don't like this. We would end with tons of different functions.

> ALTERNATIVE 2
> 
> snd_pcm_set_volume(snd_pcm_t* pcm, int vol_left, int vol_right)
> 
> but I don't expect this to be useful, since there are probably some
> oddball devices out there that aren't able to control left and right
> volume independently like this.

Same as Alternative 1...

> ALTERNATIVE 3
> 
> Let each PCM channel have its own mixer control, like the EMU10K1
> currently do. That is, use snd_pcm_info_get_subdevice() to get the
> index, then look up a volume control with a well-known name and the
> given index using the snd_ctl API to control the volume of that PCM
> stream. The name and semantics of that mixer control would have to be
> standardized and be the same on all devices that are capable of this
> feature.

This seems to me the best approach. But the control name space must be
choosen well.

> Whatever way is chosen, it's simple enough to work with.
> 
> But if we get into the realm of spatial sound, it can get trickier, of
> course. I might suggest to create a new snd_pcm_fx_params_t or
> something, which can be loaded into a PCM stream to change the volume,
> pan, or other effect. The available effects should depend on which was
> requested in hw_params. Specifically, the following effects would be
> desirable:
> 
> * Volume
> * Pan (not available if 3D sound is requested)
> * Frequency (can be used for software-calculated doppler shift, or for
> "wavetable synthesis"-like purposes)
> * 3D position (relative to listener)
> * Velocity (for hardware-calculated doppler shift)
> * Cone inside/outside angles, direction, outside volume

The above parameters can be handled by ALSA directly right now (not
implemented yet of course). Indeed i'm implementing such controls for
the aureal driver right now.

> * Min/max distance (wherever the sound is heard)

This parameters require resource management, and ALSA does not yet
provide that. I'm not sure if that can be done inside ALSA.

> There are also settings that can be considered "global" for all sounds
> in the game, but I'm not sure how they could really be considered such
> using the PCM API, so it's acceptable to have to go through every PCM
> stream and update the parameters of each one, if that's easier to
> implement. If not, there must be a way to attach each 3D-aware PCM
> stream to some kind of master structure which can hold these parameters.
> This master can be a designated PCM stream with special hw_params.
> Global settings include:
> 
> * 3D position, orientation (forward and upward directions), and velocity
> of listener, to allow streams to use absolute, not relative,
> coordinates, if they want to
> * Distance, rolloff, and doppler factors (I don't remember the exact
> semantics of these, but can look it up)

> These will be required anyway for full HW-accelerated OpenAL support, of
> course.

Yeah, I want full OpenAL too. Lets do it !

> The API should also be designed to allow for further parametrized
> effects to be applied to a particular stream, for example reverb
> effects. For what it's worth, DirectSound has currently defined Gargle,
> Chorus, Flanger, Echo, Distortion, Compressor, and a couple of Reverb
> types...

Best Regards

Manuel Jander



-------------------------------------------------------
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