trigger problems.

trigger problems.

[James Courtier-Dutton]

I am writing a alsa driver for the audigyls and p16v.
The output on these sound cards can work in 1 of two ways.
1) 1 substream with 8 channels, and one interrupt request per period.
For 5.1 output, we just use alsa.conf to map the user's application 
channels into the correct channels of the 8 channel substream.
2) 4 substreams with 2 channels each.
For 5.1 output, we just use 3 substreams, front, rear, center_lfe.
The problem with this is that we then have a separate interrupt per 
substream, resulting in 3 times more interrupts. The substreams are also 
not in sample sync with each other, because the trigger for each 
substream is executed one after the other, instead of in one go.

I don't know why exactly, maybe some audio experts can help, but (1) 
sounds a lot better than (2). I would not think that loosing sample sync 
would make so much difference, but that is the only thing that I see 
different between (1) and (2).

So, because of this, I have a feature request for alsa-driver.
If a user app opens the sound device in such a way that a single stream 
from the app gets converted into multiple substreams to the same sound 
card hardware, can we have a single trigger call for all substreams.

If we could have a single trigger call, I could start all the hardware 
substreams at the same time with a single outl() call.

To achieve this, I suggest we change the current:
static int snd_pcm_trigger_playback(
         snd_pcm_substream_t *substream,
         int cmd)
to
static int snd_pcm_trigger_playback(
         snd_pcm_substream_t **substream,
	int number_of_substreams,
         int cmd)


Any comments ?

James


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: trigger problems.

[Jaroslav Kysela]

On Wed, 14 Jul 2004, James Courtier-Dutton wrote:

> If we could have a single trigger call, I could start all the hardware 
> substreams at the same time with a single outl() call.

It's already possible. Study trident_main.c or ens1370.c code.

						Jaroslav

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


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: trigger problems.

[Takashi Iwai]

At Wed, 14 Jul 2004 13:52:45 +0100,
James Courtier-Dutton wrote:
> 
> I am writing a alsa driver for the audigyls and p16v.
> The output on these sound cards can work in 1 of two ways.
> 1) 1 substream with 8 channels, and one interrupt request per period.
> For 5.1 output, we just use alsa.conf to map the user's application 
> channels into the correct channels of the 8 channel substream.
> 2) 4 substreams with 2 channels each.
> For 5.1 output, we just use 3 substreams, front, rear, center_lfe.
> The problem with this is that we then have a separate interrupt per 
> substream, resulting in 3 times more interrupts. The substreams are also 
> not in sample sync with each other, because the trigger for each 
> substream is executed one after the other, instead of in one go.
> 
> I don't know why exactly, maybe some audio experts can help, but (1) 
> sounds a lot better than (2). I would not think that loosing sample sync 
> would make so much difference, but that is the only thing that I see 
> different between (1) and (2).
> 
> So, because of this, I have a feature request for alsa-driver.
> If a user app opens the sound device in such a way that a single stream 
> from the app gets converted into multiple substreams to the same sound 
> card hardware, can we have a single trigger call for all substreams.
> 
> If we could have a single trigger call, I could start all the hardware 
> substreams at the same time with a single outl() call.
> 
> To achieve this, I suggest we change the current:
> static int snd_pcm_trigger_playback(
>          snd_pcm_substream_t *substream,
>          int cmd)
> to
> static int snd_pcm_trigger_playback(
>          snd_pcm_substream_t **substream,
> 	int number_of_substreams,
>          int cmd)
> 
> 
> Any comments ?

We can do it with linked substreams.
For example, see ice1724 driver (snc_ice1724_pcm_trigger).

Basically, the trigger callback checks each substream belonging to the
called substream via snd_pcm_group_for_each().  If it's one of yours,
stamp it via snd_pcm_trigger_done(), so that the trigger callback to
this substream will be skipped.

BTW, both two cases above can coexist.
ice1724 drivers has two PCM devices, one for multi-channel up to 8 and
another for three indepdent 2ch-stereo streams.


Takashi


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: trigger problems.

[James Courtier-Dutton]

Takashi Iwai wrote:
> 
> 
> We can do it with linked substreams.
> For example, see ice1724 driver (snc_ice1724_pcm_trigger).
> 
> Basically, the trigger callback checks each substream belonging to the
> called substream via snd_pcm_group_for_each().  If it's one of yours,
> stamp it via snd_pcm_trigger_done(), so that the trigger callback to
> this substream will be skipped.
> 
> BTW, both two cases above can coexist.
> ice1724 drivers has two PCM devices, one for multi-channel up to 8 and
> another for three indepdent 2ch-stereo streams.
> 
> 
> Takashi
> 
> 

Thanks for the info. I implemented it, so that there is only one trigger 
register access for all 3 substreams, but even that did not help. I 
still have multiple interrrupts. I suppose it was worth a try.

I will have to think of something else.

Thanks

James


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click

RE: trigger problems.

[Giuliano Pochini]

On 14-Jul-2004 James Courtier-Dutton wrote:
> I am writing a alsa driver for the audigyls and p16v.
> The output on these sound cards can work in 1 of two ways.
> 1) 1 substream with 8 channels, and one interrupt request per period.
> For 5.1 output, we just use alsa.conf to map the user's application 
> channels into the correct channels of the 8 channel substream.

This is the simplest method of handling several channels, but you
waste some of them.


> 2) 4 substreams with 2 channels each.
> For 5.1 output, we just use 3 substreams, front, rear, center_lfe.
> The problem with this is that we then have a separate interrupt per
> substream, resulting in 3 times more interrupts. The substreams are also
> not in sample sync with each other, because the trigger for each
> substream is executed one after the other, instead of in one go.

You lose stereo image if the channels are out of sync. It also depends
on how much they are. It's generally a bad thing.


> So, because of this, I have a feature request for alsa-driver.
> If a user app opens the sound device in such a way that a single stream 
> from the app gets converted into multiple substreams to the same sound 
> card hardware, can we have a single trigger call for all substreams.

It's already possible. Grep the drivers sources for snd_pcm_set_sync()
and snd_pcm_trigger_done().  Some of them already use that feature.
Also, userspace must explicitly use it.  Have a look at the example
program latency.c (alsa-tools ?)


--
Giuliano.


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com