EMU10K1 and the extra voice

EMU10K1 and the extra voice

[Chris Purnell]

For PCM playback the EMU10K1 driver is allocating an extra voice.
This is somewhat wastefull and I kind of need all 64 voices.
Is appears to be using it to generate the period interrupts.
Does anyone know what it would take to rewrite the driver to
not need this extra voice?

-- 
Christopher John Purnell  | I thought I'd found a reason to live
http://www.lost.org.uk/   | Just like before when I was a child
--------------------------| Only to find that dreams made of sand
What gods do you pray to? | Would just fall apart and slip through my hands


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: EMU10K1 and the extra voice

[Glenn Maynard]

On Sat, Jun 05, 2004 at 12:59:36PM +0000, Chris Purnell wrote:
> For PCM playback the EMU10K1 driver is allocating an extra voice.
> This is somewhat wastefull and I kind of need all 64 voices.
> Is appears to be using it to generate the period interrupts.
> Does anyone know what it would take to rewrite the driver to
> not need this extra voice?

Any relationship to the fact that I can only allocate 21 subdevices with ALSA,
but 31 with DirectSound?

ALSA: Advanced Linux Sound Architecture Driver Version 1.0.4rc2 (Tue Mar 30 08:19:30 2004 UTC).
ALSA Driver: 0: Sound Blaster Live! [Live], device 0: emu10k1 [EMU10K1], 32/32 subdevices avail
ALSA Driver: 0: Sound Blaster Live! [Live], device 3: emu10k1 [EMU10K1 FX8010], 8/8 subdevices avail
ALSA: dsnd_pcm_hw_params: Cannot allocate memory
ALSA: Got 21 hardware buffers

vs

DirectSound Driver: SB Live! Audio [FF80] (ctaud2k.sys)
    ID: {bd6dd71a-3deb-11d1-1252b90}
DirectSound sample rates: 4000..191999 (continuous)
Got 31 hardware buffers

-- 
Glenn Maynard


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: EMU10K1 and the extra voice

[Jaroslav Kysela]

On Sat, 5 Jun 2004, Chris Purnell wrote:

> For PCM playback the EMU10K1 driver is allocating an extra voice.
> This is somewhat wastefull and I kind of need all 64 voices.
> Is appears to be using it to generate the period interrupts.
> Does anyone know what it would take to rewrite the driver to
> not need this extra voice?

I'm not sure, if it's possible in a simple way. The extra voice is
required to do the proper interrupt acknowledge. If I remember correctly,
the interrupts are going faster than voice position otherwise.

Anyway, it wouldn't be a big problem to update driver and create a new 
(ONE!) PCM device with multiple mixed channels (up to 63).

						Jaroslav

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


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: EMU10K1 and the extra voice

[Jaroslav Kysela]

On Sun, 6 Jun 2004, Glenn Maynard wrote:

> On Sat, Jun 05, 2004 at 12:59:36PM +0000, Chris Purnell wrote:
> > For PCM playback the EMU10K1 driver is allocating an extra voice.
> > This is somewhat wastefull and I kind of need all 64 voices.
> > Is appears to be using it to generate the period interrupts.
> > Does anyone know what it would take to rewrite the driver to
> > not need this extra voice?
> 
> Any relationship to the fact that I can only allocate 21 subdevices with
> ALSA, but 31 with DirectSound?

Yes, 64 / 3 = 21 .

						Jaroslav

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


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: EMU10K1 and the extra voice

[Glenn Maynard]

On Sun, Jun 06, 2004 at 12:40:31PM +0200, Jaroslav Kysela wrote:
> > Any relationship to the fact that I can only allocate 21 subdevices with
> > ALSA, but 31 with DirectSound?
> 
> Yes, 64 / 3 = 21 .

That stinks (but if it's necessary for decent latency, which it doesn't
get in Windows, oh well).  Shouldn't the driver report 21 substreams
instead of 32, though?

-- 
Glenn Maynard


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: EMU10K1 and the extra voice

[Jaroslav Kysela]

On Sun, 6 Jun 2004, Glenn Maynard wrote:

> On Sun, Jun 06, 2004 at 12:40:31PM +0200, Jaroslav Kysela wrote:
> > > Any relationship to the fact that I can only allocate 21 subdevices with
> > > ALSA, but 31 with DirectSound?
> > 
> > Yes, 64 / 3 = 21 .
> 
> That stinks (but if it's necessary for decent latency, which it doesn't
> get in Windows, oh well).  Shouldn't the driver report 21 substreams
> instead of 32, though?

Nope. For mono streams - 64 / 2 = 32.

						Jaroslav

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


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: EMU10K1 and the extra voice

[Chris Purnell]

On Sun, Jun 06, 2004 at 12:38:22PM +0200, Jaroslav Kysela wrote:
> On Sat, 5 Jun 2004, Chris Purnell wrote:
> 
> > For PCM playback the EMU10K1 driver is allocating an extra voice.
> > This is somewhat wastefull and I kind of need all 64 voices.
> > Is appears to be using it to generate the period interrupts.
> > Does anyone know what it would take to rewrite the driver to
> > not need this extra voice?
> 
> I'm not sure, if it's possible in a simple way. The extra voice is
> required to do the proper interrupt acknowledge. If I remember correctly,
> the interrupts are going faster than voice position otherwise.
> 
> Anyway, it wouldn't be a big problem to update driver and create a new 
> (ONE!) PCM device with multiple mixed channels (up to 63).

I've been having a look at how the other driver work (that is the
oss like driver in the linux kernel).  It uses the sound cards timer
interrupt.  Which the alsa driver appears not to be using at all.
What it does is set the timer interval to that of the shotest period
time in use.  If a period time is twice that of the timer interval is
it serviced every other timer interrupt.  If it is three times ... etc.
That way you tipically get an interrupt slightly more often than end of
the period.

If you are going to use a single timing device for all PCM devices
I don't see any advantage of using a PCM voice over the cards timer.
But they may be a better way to use it than the other driver.

Another concern I have about using a PCM voice for timing is
all those wasted DMA cycles.

What I was wanting all those PCM voices for was OpenAL sources.
I'm writing a OpenAL that uses the hardware mixing capabilities
of the emu10k1 series sound cards.  It's almost there but I've
come across a bigger problem.  It is much faster to use the
existing, software mixing, OpenAL.  I've gone over my code and
it is definitly doing less work.  Some there must be something
simultaneously using all those PCM devices that is slowing my
computer down.  There could be some large overhead starting or
stopping the PCM devices.  It could be all those extra interrupts
or all the extra data going over the PCI bus.  I don't know.
I'm going to have to do some more testing.

-- 
Christopher John Purnell  | I thought I'd found a reason to live
http://www.lost.org.uk/   | Just like before when I was a child
--------------------------| Only to find that dreams made of sand
What gods do you pray to? | Would just fall apart and slip through my hands


-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org

Re: EMU10K1 and the extra voice

[Jaroslav Kysela]

On Wed, 9 Jun 2004, Chris Purnell wrote:

> On Sun, Jun 06, 2004 at 12:38:22PM +0200, Jaroslav Kysela wrote:
> > On Sat, 5 Jun 2004, Chris Purnell wrote:
> > 
> > > For PCM playback the EMU10K1 driver is allocating an extra voice.
> > > This is somewhat wastefull and I kind of need all 64 voices.
> > > Is appears to be using it to generate the period interrupts.
> > > Does anyone know what it would take to rewrite the driver to
> > > not need this extra voice?
> > 
> > I'm not sure, if it's possible in a simple way. The extra voice is
> > required to do the proper interrupt acknowledge. If I remember correctly,
> > the interrupts are going faster than voice position otherwise.
> > 
> > Anyway, it wouldn't be a big problem to update driver and create a new 
> > (ONE!) PCM device with multiple mixed channels (up to 63).
> 
> I've been having a look at how the other driver work (that is the
> oss like driver in the linux kernel).  It uses the sound cards timer
> interrupt.  Which the alsa driver appears not to be using at all.
> What it does is set the timer interval to that of the shotest period
> time in use.  If a period time is twice that of the timer interval is
> it serviced every other timer interrupt.  If it is three times ... etc.
> That way you tipically get an interrupt slightly more often than end of
> the period.

1. how you ensure that PCM stream starts EXACTLY at timer interrupt?
2. I prefer to reserve timer for sequencer purposes

> Another concern I have about using a PCM voice for timing is
> all those wasted DMA cycles.

If we create a PCM with multiple channels (3+) then the overhead is 
minimal, because only one voice will do this timing job. Also we reduce 
the interrupt handler / stream position overhead.

> What I was wanting all those PCM voices for was OpenAL sources.
> I'm writing a OpenAL that uses the hardware mixing capabilities
> of the emu10k1 series sound cards.  It's almost there but I've
> come across a bigger problem.  It is much faster to use the
> existing, software mixing, OpenAL.  I've gone over my code and
> it is definitly doing less work.  Some there must be something
> simultaneously using all those PCM devices that is slowing my
> computer down.  There could be some large overhead starting or
> stopping the PCM devices.  It could be all those extra interrupts
> or all the extra data going over the PCI bus.  I don't know.
> I'm going to have to do some more testing.

Yes, I'm interested, too. But simple expression shows that 64 voices 
saturates about 5% of the PCI bus at 48kHz:

48000 * 2 = 96000
96000 * 64 = 6144000
6144000 bytes = 6MB/sec (comparing 133MB/sec - teoretical PCI limit)

Of course, there is always some overhead with non-busmaster-DMA PCI 
transactions, but I think that we don't go above 10% of the bus 
saturation.

						Jaroslav

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


-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org

Re: EMU10K1 and the extra voice

[Chris Purnell]

On Wed, Jun 09, 2004 at 09:21:42AM +0200, Jaroslav Kysela wrote:
> On Wed, 9 Jun 2004, Chris Purnell wrote:

> > I've been having a look at how the other driver work (that is the
> > oss like driver in the linux kernel).  It uses the sound cards timer
> > interrupt.  Which the alsa driver appears not to be using at all.
> > What it does is set the timer interval to that of the shotest period
> > time in use.  If a period time is twice that of the timer interval is
> > it serviced every other timer interrupt.  If it is three times ... etc.
> > That way you tipically get an interrupt slightly more often than end of
> > the period.
> 
> 1. how you ensure that PCM stream starts EXACTLY at timer interrupt?

The OSS style driver doesn't.  It just ensures that the interrupts happen
often enough to keep filling the buffer.

> 2. I prefer to reserve timer for sequencer purposes

If you think it will ever been used for that pourose.


I did think of a simple change that might have allowed me to do what I
want.  And that was to not allocate the extra voice when the number of
periods was one.  However when I set the number of periods to 1 I got
stuttering.  What I'm going is periodically calling
snd_pcm_avail_update(), snd_pcm_mmap_begin() and snd_pcm_mmap_commit()
without using ALSA for timing.  So if anyone was going to get away
with setting the number periods to 1 I thought I would.  Do you know
why that didn't work?


> > What I was wanting all those PCM voices for was OpenAL sources.
> > I'm writing a OpenAL that uses the hardware mixing capabilities
> > of the emu10k1 series sound cards.  It's almost there but I've
> > come across a bigger problem.  It is much faster to use the
> > existing, software mixing, OpenAL.  I've gone over my code and
> > it is definitly doing less work.  Some there must be something
> > simultaneously using all those PCM devices that is slowing my
> > computer down.  There could be some large overhead starting or
> > stopping the PCM devices.  It could be all those extra interrupts
> > or all the extra data going over the PCI bus.  I don't know.
> > I'm going to have to do some more testing.
> 
> Yes, I'm interested, too.

I've found out what the problem was.  I had left the bit where
I specify the period size and number commented out.  So it was
setting the period size as small as the driver would let it.
And so my computer was being overwhelmed with all those
interrupts.

-- 
Christopher John Purnell  | I thought I'd found a reason to live
http://www.lost.org.uk/   | Just like before when I was a child
--------------------------| Only to find that dreams made of sand
What gods do you pray to? | Would just fall apart and slip through my hands


-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org