emu10k1 device naming

emu10k1 device naming

[Lee Revell]

Now that the emu10k1 driver supports low latency, multichannel capture,
it would be useful to rearrange the devices.  Currently you have to use
hw:0,0 for playback, and hw:0,2 for capture.  This works down to 32
frames (you have to record more than 2 channels to get 32 frames,
because 512 bytes is the smallest period JACK supports).  JACK requires
the playback and capture device to be the same for both directions.

The current hw:0,0 device could be moved to hw:0,2.  This is the best
arrangement, because these are the only two devices that it makes sense
to use for full-duplex.  The hw:0,2 playback device is a special AC3
passthrough device, there is no capture device that corresponds to it. 
The same applies to the current hw:0,0 (ADC capture) and hw:0,1 (mic
capture - 8000 Hz) devices, there is no corresponding playback device.

It was suggsted to use the 'asym' PCM plugin for this, but JACK does not
support using a PCM as the device name, you need to give it a hardware
device.

Lee 





-------------------------------------------------------
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: emu10k1 device naming

[Jaroslav Kysela]

On Sun, 25 Jul 2004, Lee Revell wrote:

> Now that the emu10k1 driver supports low latency, multichannel capture,
> it would be useful to rearrange the devices.  Currently you have to use
> hw:0,0 for playback, and hw:0,2 for capture.  This works down to 32
> frames (you have to record more than 2 channels to get 32 frames,
> because 512 bytes is the smallest period JACK supports).  JACK requires
> the playback and capture device to be the same for both directions.
> 
> The current hw:0,0 device could be moved to hw:0,2.  This is the best
> arrangement, because these are the only two devices that it makes sense
> to use for full-duplex.  The hw:0,2 playback device is a special AC3
> passthrough device, there is no capture device that corresponds to it. 
> The same applies to the current hw:0,0 (ADC capture) and hw:0,1 (mic
> capture - 8000 Hz) devices, there is no corresponding playback device.
> 
> It was suggsted to use the 'asym' PCM plugin for this, but JACK does not
> support using a PCM as the device name, you need to give it a hardware
> device.

JACK should be corrected. Complain there. I wonder why people always fix 
the drivers instead of applications.

						Jaroslav

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


-------------------------------------------------------
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: emu10k1 device naming

[Lee Revell]

On Sun, 2004-07-25 at 04:15, Jaroslav Kysela wrote:
> On Sun, 25 Jul 2004, Lee Revell wrote:
> 
> > Now that the emu10k1 driver supports low latency, multichannel capture,
> > it would be useful to rearrange the devices.  Currently you have to use
> > hw:0,0 for playback, and hw:0,2 for capture.  This works down to 32
> > frames (you have to record more than 2 channels to get 32 frames,
> > because 512 bytes is the smallest period JACK supports).  JACK requires
> > the playback and capture device to be the same for both directions.
> > 
> > The current hw:0,0 device could be moved to hw:0,2.  This is the best
> > arrangement, because these are the only two devices that it makes sense
> > to use for full-duplex.  The hw:0,2 playback device is a special AC3
> > passthrough device, there is no capture device that corresponds to it. 
> > The same applies to the current hw:0,0 (ADC capture) and hw:0,1 (mic
> > capture - 8000 Hz) devices, there is no corresponding playback device.
> > 
> > It was suggsted to use the 'asym' PCM plugin for this, but JACK does not
> > support using a PCM as the device name, you need to give it a hardware
> > device.
> 
> JACK should be corrected. Complain there. I wonder why people always fix 
> the drivers instead of applications.
> 

Good point, this would be much easier to correct in JACK, than fix every
driver to conform.  There actually is no 1:1 correspondence between any
of the capture and playback devices, so it's arbitrary to require the
playback and a capture device to have the same hw index.

Lee



-------------------------------------------------------
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: emu10k1 device naming

[Jaroslav Kysela]

On Sun, 25 Jul 2004, Lee Revell wrote:

> Good point, this would be much easier to correct in JACK, than fix every
> driver to conform.  There actually is no 1:1 correspondence between any
> of the capture and playback devices, so it's arbitrary to require the
> playback and a capture device to have the same hw index.

I don't agree so much, because the most of users of the emu10k1 driver 
want to use card only for VoIP, games and some amateur recording. For this 
case, the first playback and capture devices are quite sufficient. Our 
goal is to provide the basics functionality for first subdevices.

						Jaroslav

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


-------------------------------------------------------
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: emu10k1 device naming

[Takashi Iwai]

At Tue, 27 Jul 2004 08:55:05 +0200 (CEST),
Jaroslav wrote:
> 
> On Sun, 25 Jul 2004, Lee Revell wrote:
> 
> > Good point, this would be much easier to correct in JACK, than fix every
> > driver to conform.  There actually is no 1:1 correspondence between any
> > of the capture and playback devices, so it's arbitrary to require the
> > playback and a capture device to have the same hw index.
> 
> I don't agree so much, because the most of users of the emu10k1 driver 
> want to use card only for VoIP, games and some amateur recording. For this 
> case, the first playback and capture devices are quite sufficient. Our 
> goal is to provide the basics functionality for first subdevices.

Hmm, but there is no big disadvantage to use EFX for the default
capture...  Or do we have any?


Takashi


-------------------------------------------------------
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: emu10k1 device naming

[Jaroslav Kysela]

On Tue, 27 Jul 2004, Takashi Iwai wrote:

> Hmm, but there is no big disadvantage to use EFX for the default
> capture...  Or do we have any?

Hardware rate conversions.

					Jaroslav

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


-------------------------------------------------------
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: emu10k1 device naming

[Lee Revell]

On Tue, 2004-07-27 at 13:38, Jaroslav Kysela wrote:
> On Tue, 27 Jul 2004, Takashi Iwai wrote:
> 
> > Hmm, but there is no big disadvantage to use EFX for the default
> > capture...  Or do we have any?
> 
> Hardware rate conversions.
> 

Correct, I did not think of this.  The current default allows stereo
capture and playback at any sample rate, albeit at the expense of
multichannel, low latency capabilities.  This is the best default.

The other problem with the FX capture device is that currently the only
way to select the channels to record is to manually edit asound.state
and then do alsactl restore.  To put this in the mixer, we would need to
add 'EFX Voices Mask', consisting of 64 boolean values, and the number
of these which are unmuted at any given time must be a power of two.
Not sure if this is possible with the current mixer API, it certainly
would not be pretty.

Anyway, this issue is moot, because it turns out that JACK does support
full-duplex mode using different devices for capture and playback.  The
documentation and help text was incorrect.  This will be fixed in the
next JACK release.

The next release of qjackctl will also be updated to reflect this
development, as qjackctl currently disables the selection of input and
output devices if full duplex mode is selected.

Lee



-------------------------------------------------------
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: emu10k1 device naming

[Takashi Iwai]

At Tue, 27 Jul 2004 15:17:06 -0400,
Lee Revell wrote:
> 
> The other problem with the FX capture device is that currently the only
> way to select the channels to record is to manually edit asound.state
> and then do alsactl restore.

You can change it via amixer, too, although it's not intuitive.


Takashi


-------------------------------------------------------
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: emu10k1 device naming

[Lee Revell]

On Wed, 2004-07-28 at 11:16, Takashi Iwai wrote:
> At Tue, 27 Jul 2004 15:17:06 -0400,
> Lee Revell wrote:
> > 
> > The other problem with the FX capture device is that currently the only
> > way to select the channels to record is to manually edit asound.state
> > and then do alsactl restore.
> 
> You can change it via amixer, too, although it's not intuitive.
> 

Now I see the need for the integrated LISP...

Lee



-------------------------------------------------------
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: emu10k1 device naming

[Florian Schmidt]

On Sun, 25 Jul 2004 00:29:27 -0400
Lee Revell <rlrevell@joe-job.com> wrote:

> Now that the emu10k1 driver supports low latency, multichannel capture,
> it would be useful to rearrange the devices.  Currently you have to use
> hw:0,0 for playback, and hw:0,2 for capture.  This works down to 32
> frames (you have to record more than 2 channels to get 32 frames,
> because 512 bytes is the smallest period JACK supports).  JACK requires
> the playback and capture device to be the same for both directions.

Actually jack supports period sizes smaller than 512 frames. I can easily start jackd with a period size of 64 frames. This is not a limitation of jackd but rather of your soundcard.

> 
> The current hw:0,0 device could be moved to hw:0,2.  This is the best
> arrangement, because these are the only two devices that it makes sense
> to use for full-duplex.  The hw:0,2 playback device is a special AC3
> passthrough device, there is no capture device that corresponds to it. 
> The same applies to the current hw:0,0 (ADC capture) and hw:0,1 (mic
> capture - 8000 Hz) devices, there is no corresponding playback device.
> 
> It was suggsted to use the 'asym' PCM plugin for this, but JACK does not
> support using a PCM as the device name, you need to give it a hardware
> device.

jackd also supports using non hw pcm devices. it should only spit out a warning to the user.. I just tried and besides some other weird behaviour it hardlocked my machine.. So this might be a bug that should be reported to the jack people.. But by design it should work..

One other thing that bothers me about jack is that it requires a ctl device by the same name as the used pcm device [which is only needed in the case of hw monitoring].. For people who don't need hw monitoring, this should not be required.. I'll write to jackit-devel about this [forwarding this mail :)]..

Flo

-- 
Palimm Palimm!
http://affenbande.org/~tapas/



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