Re: questions for alsa-devel

Re: questions for alsa-devel

[Thierry Vignaud]

Paul Davis <pbd@op.net> writes:

> > hum, mdk9.0 is compiled with module versionning and we've no
> > problems (i mean there're bugs but not such problems)
>
> this is 8.2 ...

this means that we compile rc3 with versionning symbols without
problems, so this answer takashi fear

> i have a bit of a problem with all of this. why doesn't ALSA build
> "out of the box"? the description you've given of what is necessary
> to get this to work seems (for the most part) to be a bit
> ridiculous.

insulting people that take time to answer you has always been a
constructive & efficient communication way.

> > 4) note that if you boot with a kernel with alsa-0.9.0, all your
> >    alsa apps won't work unless you use them in oss emulation mode.
>
> why is this? note that i never compile ALSA as part of the kernel,
> and i doubt that i ever will, even when 2.5/2.6/3.0 comes out. i
> prefer to be able to update my drivers without touching my kernel
> source.

the problem will remains the same whatever you compiled the alsa
modules in the same time you compiled the kernel or as a separate
pacakge : applications linked with alsa-0.5 library won't be able to
dialog with alsa-0.9.0 kernel ...

> updating from 8.2 to 9.0 over a 56k link strikes me as a pretty
> absurd step to take.

then, unless you absolutely need the fixes provided by the latest alsa
driver for your card, there's no point in upgrading it without
upgrading libalsa and relevant applications...

> having to specifically install kernel source to compile ALSA (and
> presumably other drivers) seems very odd to me. i would understand
> if ALSA just failed to compile without that step, but i didn't ask
> for or say no to a kernel source package, and ALSA compiled just
> fine.

alsa can compile fine as an extra package providing you've kernel
headers and the right links in /boot and /lib/modules (config, build,
System.map, ...)

> frankly, i was very suprised to get ALSA 0.5 in mdk8.2. its been
> publically stated for months and months that 0.5 is no longer under
> development and is not really supported (though takashi has done a
> great job with it). i did a quick search with rpmdrake to see if a
> 0.9.0 rpm was on the installation disks, but i couldn't find it.

mdk8.2 is more than 6 monthes old; i don't have yet time support in
tcp/ip to download future version of alsa-0.9.0 when only stable
versions of alsa-0.5.x were out...

the point of alsa-0.5.x integration in mandrake kernel was more
drivers (there're lots of cards not supported by oss drivers but by
alsa. eg the fm801 i used to have)

we also put the corresponding alsa libs and tools since they enable
some more features in some apps.

if you want less drivers and less features, that's your problem.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Forward: Re: questions for alsa-devel

[Takashi Iwai]

[-- Attachment #0: Type: message/rfc822, Size: 3622 bytes --]

From: Paul Davis <pbd@op.net>
To: Thierry Vignaud <tvignaud@mandrakesoft.com>
Cc: Takashi Iwai <tiwai@suse.de>, alsa-devel@lists.sourceforge.net
Subject: Re: questions for alsa-devel
Date: Wed, 02 Oct 2002 10:58:44 -0400
Message-ID: <20021002145420.6F590146FB@Cantor.suse.de>

   [ the usual forward request for alsa-devel@lists.sourceforge.net ]

>> i have a bit of a problem with all of this. why doesn't ALSA build
>> "out of the box"? the description you've given of what is necessary
>> to get this to work seems (for the most part) to be a bit
>> ridiculous.
>
>insulting people that take time to answer you has always been a
>constructive & efficient communication way.

sorry, i wasn't trying to be insulting. its just that my experience of
using ALSA for several years when built with a kernel from kernel.org
has been that i just type:

     cd .../alsa-cvs/alsa-{driver,lib,utils}
then
     cvscompile
or
     ./configure && make && make install

and it works. i was very suprised when this did not happen with my new
mandrake system.

>the problem will remains the same whatever you compiled the alsa
>modules in the same time you compiled the kernel or as a separate
>pacakge : applications linked with alsa-0.5 library won't be able to
>dialog with alsa-0.9.0 kernel ...

which applications are they? i know of very few ALSA apps that use
0.5, and to be honest, i think it would be much better for mandrake to
not distribute them.

>> updating from 8.2 to 9.0 over a 56k link strikes me as a pretty
>> absurd step to take.
>
>then, unless you absolutely need the fixes provided by the latest alsa
>driver for your card, there's no point in upgrading it without
>upgrading libalsa and relevant applications...

the applications mean nothing to me, since i write audio apps for
linux, and any existing ones that use 0.5 are not of much use to me
for many different reasons.

i know about the rest of ALSA. thierry, perhaps you don't know that
i've been a significant contributor to ALSA for several years,
including writing 3 lowlevel drivers, and participating in design
discussions and general bitching sessions on alsa-devel for quite some
time now.

>> having to specifically install kernel source to compile ALSA (and
>> presumably other drivers) seems very odd to me. i would understand
>> if ALSA just failed to compile without that step, but i didn't ask
>> for or say no to a kernel source package, and ALSA compiled just
>> fine.
>
>alsa can compile fine as an extra package providing you've kernel
>headers and the right links in /boot and /lib/modules (config, build,
>System.map, ...)

well, i haven't changed any of that stuff since the install of mdk8.2,
alsa compiled just fine, but you can't modprobe any of the results due
to missing symbols.

>if you want less drivers and less features, that's your problem.

no, i just wanted a system that would work. microtel shipped me a
system with an audio chip not properly supported by ALSA 0.5. since
i've been using ALSA for 3 or 4 years now, i naturally assumed that it
would be simple to compile and install 0.9. it seems i was wrong about
that. 

--p

ps. you probably know about the related problems with microtel
    shipping systems with a video chipset not properly supported
    by either the kernel framebuffer or X11. this isn't a purely
    sound-related issue :)

	



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Forward: Re: questions for alsa-devel

[Takashi Iwai]

> >> i have a bit of a problem with all of this. why doesn't ALSA build
> >> "out of the box"? the description you've given of what is necessary
> >> to get this to work seems (for the most part) to be a bit
> >> ridiculous.
> >
> >insulting people that take time to answer you has always been a
> >constructive & efficient communication way.
> 
> sorry, i wasn't trying to be insulting. its just that my experience of
> using ALSA for several years when built with a kernel from kernel.org
> has been that i just type:
> 
>      cd .../alsa-cvs/alsa-{driver,lib,utils}
> then
>      cvscompile
> or
>      ./configure && make && make install
> 
> and it works. i was very suprised when this did not happen with my new
> mandrake system.
 
the problem is that many different kernel binaries are built using the
same kernel tree, i.e. there are many different kernel configs while
there is only one kernel-source package.
thus you have to adjust the kernel config by yourself anyway.

in case building the kernel from scratach, you'll surely configure the
tree once in prior to build of alsa modules.  this ensures you having
the correct kernel tree.
but in the case of distro's kernel package, the default configuration
might not match with the running kernel unless you set up properly.
and, much worse is that this small "tune-up" is dependent on each
distro (for example, the location of config files, etc.)

it might be possible to hack a spec file to change such things
automatically.  but, as you know, hacking a spec file is awesome and
makes the situation more more complicated ;)


> >> having to specifically install kernel source to compile ALSA (and
> >> presumably other drivers) seems very odd to me. i would understand
> >> if ALSA just failed to compile without that step, but i didn't ask
> >> for or say no to a kernel source package, and ALSA compiled just
> >> fine.
> >
> >alsa can compile fine as an extra package providing you've kernel
> >headers and the right links in /boot and /lib/modules (config, build,
> >System.map, ...)
> 
> well, i haven't changed any of that stuff since the install of mdk8.2,
> alsa compiled just fine, but you can't modprobe any of the results due
> to missing symbols.
 
the modules can be compiled without any complains even with a wrong
(i mean, mismatching) configuration.  please check the kernel config
again.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Forward: Re: questions for alsa-devel

[Matthias Saou]

Once upon a time, Takashi wrote :

> the problem is that many different kernel binaries are built using the
> same kernel tree, i.e. there are many different kernel configs while
> there is only one kernel-source package.
> thus you have to adjust the kernel config by yourself anyway.
> 
> in case building the kernel from scratach, you'll surely configure the
> tree once in prior to build of alsa modules.  this ensures you having
> the correct kernel tree.
> but in the case of distro's kernel package, the default configuration
> might not match with the running kernel unless you set up properly.
> and, much worse is that this small "tune-up" is dependent on each
> distro (for example, the location of config files, etc.)
> 
> it might be possible to hack a spec file to change such things
> automatically.  but, as you know, hacking a spec file is awesome and
> makes the situation more more complicated ;)

I've managed to work something out for Red Hat Linux that should be easily
portable to Mandrake I guess (then again, they already have ALSA 0.5.x
built in, is that what I understood from the last few mails??). I have a
single "alsa-driver" source package which builds a binary "alsa-driver" one
containing the include files and the device entries (in a tricky way by
adding a file to /etc/makedev.d/ in order to package the device entries
even while building as non-root), and another "alsa-kernel" one which
matches the currently running kernel's package.

For Red Hat Linux 8.0, I've got these :

alsa-driver-0.9.0rc3-fr11.i586.rpm
alsa-driver-0.9.0rc3-fr11.src.rpm
alsa-kernel-0.9.0rc3-fr11_2.4.18_14.athlon.rpm
alsa-kernel-0.9.0rc3-fr11_2.4.18_14.i586.rpm
alsa-kernel-0.9.0rc3-fr11_2.4.18_14.i686.rpm
alsa-kernel-smp-0.9.0rc3-fr11_2.4.18_14.athlon.rpm
alsa-kernel-smp-0.9.0rc3-fr11_2.4.18_14.i686.rpm

And even apt for rpm is able to install the correct package when used.
Ain't it easy? All these are easily built by having the "kernel-source"
package installed (the same for all archs), and while running the kernel to
build for so that SMP and CPU arch are detected correctly :-)

You can take a look at all my spec files from here :
http://freshrpms.net/builds/index.html?sort=name

And all binary / source packages from here :
http://psyche.freshrpms.net/

This is quite Red Hat Linux specific, but as Mandrake's way of naming and
managing rpms is close, things may work with minor tweaking.

Of course, this doesn't apply for "home made kernels" for which you should
always keep the source tree and rebuild the ALSA modules against it "by
hand" too.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Red Hat Linux release 7.3 (Valhalla) running Linux kernel 2.4.18-10acpi
Load : 0.15 0.23 0.37


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Forward: Re: questions for alsa-devel

[Thierry Vignaud]

Matthias Saou <matthias@rpmforge.net> writes:

> I've managed to work something out for Red Hat Linux that should be
> easily portable to Mandrake I guess (then again, they already have
> ALSA 0.5.x built in, is that what I understood from the last few
> mails??).

yep, we shipped alsa-0.5.x for quite some times, at least since
december 2000 (and i believe a few month before), that is since mdk8.0
i think.

between mdk8.2 (released in very early 2002) and mdk9.0 (released a
few days ago), we switched from alsa 0.5.x to alsa-0.9.x

> I have a single "alsa-driver" source package which builds a binary
> "alsa-driver" one containing the include files and the device
> entries (in a tricky way by adding a file to /etc/makedev.d/ in
> order to package the device entries even while building as
> non-root), and another "alsa-kernel" one which matches the currently
> running kernel's package.

since it must be rebuild for each kernel, we integrated in our kernel
package (first as a separate tarball with configure/make/..., now we
untar it under sound in kernel linux sources and apply a few patches
to config.in so that there's one make to run)



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Forward: Re: questions for alsa-devel

[Matthias Saou]

Once upon a time, Thierry wrote :

> since it must be rebuild for each kernel, we integrated in our kernel
> package (first as a separate tarball with configure/make/..., now we
> untar it under sound in kernel linux sources and apply a few patches
> to config.in so that there's one make to run)

Thanks for those precisions :-)
So I guess that in some ways, having nothing whatsoever related to ALSA in
Red Hat Linux does make things easier. The main concern is to then have
ALSA support in the applications, but most of my packages provide that with
their "--with alsa" rpmrebuild option.

All this will get so much easier once stable kernels used by Linux
distributions come with ALSA by default ;-)

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Red Hat Linux release 7.3 (Valhalla) running Linux kernel 2.4.18-10acpi
Load : 0.10 0.23 0.29


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Forward: Re: questions for alsa-devel

[Jack O'Quin]

Matthias Saou <matthias@rpmforge.net> writes:

> All this will get so much easier once stable kernels used by Linux
> distributions come with ALSA by default ;-)

Sure will.  

Providing we stay focused on maintaining binary compatibility...  :-)
-- 
  Jack O'Quin
  Austin, Texas, USA
  http://www.stellajazz.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Forward: Re: questions for alsa-devel

[Thierry Vignaud]

Matthias Saou <matthias@rpmforge.net> writes:

> All this will get so much easier once stable kernels used by Linux
> distributions come with ALSA by default ;-)

suse & mandrake come with alsa in their kernel, debian has a package,
rh doesn't

since linus posts on klm seems to indicate we'll have a new stable
branch sooner that most believed[1], we may expect most distro to ship
kernel-2.6.x in one year (or 6 month for fast integration if linus
release 2.6.0, if 2.6.x get stale fast enough, ...)

[1] well, we can still do the "i freeze", wait 6 month, "i really
    freeze", wait a few month of 2.3.9x and test kernels as was di
    for the 2.4.x branch :-(



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Audiophile 2496 S/PDIF Support

[Robert Robinson]

This is a re-post. We are still interested to know if work is planned to
implement digital I/O support for the M-Audio Audiophile 2496. Analog I/O
works fine with ALSA.
Thank you.
Robbie



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Audiophile 2496 S/PDIF Support

[Jaroslav Kysela]

On Wed, 2 Oct 2002, Robert Robinson wrote:

> This is a re-post. We are still interested to know if work is planned to
> implement digital I/O support for the M-Audio Audiophile 2496. Analog I/O
> works fine with ALSA.

Note that support for digital I/O is in the driver. You may reach a small 
bug, of course. I have not a spare time to debug this problem at a moment.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Audiophile 2496 S/PDIF Support

[Robert Robinson]

Jaroslav,
Thank you very much for the follow-up.
Robbie
----- Original Message -----
From: "Jaroslav Kysela" <perex@suse.cz>
To: "Robert Robinson" <robbiex@bellsouth.net>
Cc: <alsa-devel@lists.sourceforge.net>
Sent: Thursday, October 03, 2002 3:22 AM
Subject: Re: [Alsa-devel] Audiophile 2496 S/PDIF Support


> On Wed, 2 Oct 2002, Robert Robinson wrote:
>
> > This is a re-post. We are still interested to know if work is planned to
> > implement digital I/O support for the M-Audio Audiophile 2496. Analog
I/O
> > works fine with ALSA.
>
> Note that support for digital I/O is in the driver. You may reach a small
> bug, of course. I have not a spare time to debug this problem at a moment.
>
> Jaroslav
>
> -----
> Jaroslav Kysela <perex@suse.cz>
> Linux Kernel Sound Maintainer
> ALSA Project  http://www.alsa-project.org
> SuSE Linux    http://www.suse.com
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
>



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Audiophile 2496 S/PDIF Support

[Takashi Iwai]

At Wed, 2 Oct 2002 17:49:57 -0400,
Robert Robinson wrote:
> 
> This is a re-post. We are still interested to know if work is planned to
> implement digital I/O support for the M-Audio Audiophile 2496. Analog I/O
> works fine with ALSA.

could you elaborate the problem?
how did you test spdif on that hardware?
the spdif is already implemented but it might be broken since the last
change.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Audiophile 2496 S/PDIF Support

[Robert Robinson]

Takashi,

I had communication from Kysela Jaroslav indicating that the Audiophile 2496
driver does support digital I/O.
The problem may be that I have not been using an audio interface program
that supports the digital option. This choice is never displayed as part of
the I/O.
Robbie
----- Original Message -----
From: "Takashi Iwai" <tiwai@suse.de>
To: "Robert Robinson" <robbiex@bellsouth.net>
Cc: <alsa-devel@lists.sourceforge.net>
Sent: Friday, October 04, 2002 7:43 AM
Subject: Re: [Alsa-devel] Audiophile 2496 S/PDIF Support


> At Wed, 2 Oct 2002 17:49:57 -0400,
> Robert Robinson wrote:
> >
> > This is a re-post. We are still interested to know if work is planned to
> > implement digital I/O support for the M-Audio Audiophile 2496. Analog
I/O
> > works fine with ALSA.
>
> could you elaborate the problem?
> how did you test spdif on that hardware?
> the spdif is already implemented but it might be broken since the last
> change.
>
>
> Takashi
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
>



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

multiple devices per card?

[Guilhem Tardy]

Hi,

I am unsure what makes the most sense for multiple pcm channels on the same
card:
 a) N devices, 1 pcm channel each
 b) 1 device, N pcm channels each

In the same vein, is the mixer always one per card?

Thanks,
Guilhem.


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: multiple devices per card?

[Patrick Shirkey]

Guilhem Tardy wrote:
> Hi,
> 
> I am unsure what makes the most sense for multiple pcm channels on the same
> card:
>  a) N devices, 1 pcm channel each
>  b) 1 device, N pcm channels each
> 
> In the same vein, is the mixer always one per card?
> 

well if we have hw:0,0 hw:0,1 hw:0,2

Then it looks like option b to me. But Jaroslav confused me recently by 
saying something that sounded like a is the case.



-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: multiple devices per card?

[Jaroslav Kysela]

On Sat, 5 Oct 2002, Patrick Shirkey wrote:

> Guilhem Tardy wrote:
> > Hi,
> > 
> > I am unsure what makes the most sense for multiple pcm channels on the same
> > card:
> >  a) N devices, 1 pcm channel each
> >  b) 1 device, N pcm channels each
> > 
> > In the same vein, is the mixer always one per card?
> > 
> 
> well if we have hw:0,0 hw:0,1 hw:0,2
> 
> Then it looks like option b to me. But Jaroslav confused me recently by 
> saying something that sounded like a is the case.

Nope. If channels are linked together in hardware, they should be used as 
one device. I think that our discussion was about subdevices. Here is the 
hiearchy:

card -+- device -+- subdevice
      |          |
      |          +- subdevice
      |          |
      |          ...
      |
      +- device -+- subdevice
      |          |
      |          ...
      |
      ...

In PCM API, there might be several PCM devices and several subdevices per 
a PCM device. The subdevices are used mostly for multi-open hardware, but 
if hardware offers for example 512 independent stereo streams with 1024 
discrete hardware outputs, it could use subdevices as well, because we 
have limited count of devices.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Audiophile 2496 S/PDIF Support

[James Courtier-Dutton]

Robert Robinson wrote:

>Takashi,
>
>I had communication from Kysela Jaroslav indicating that the Audiophile 2496
>driver does support digital I/O.
>The problem may be that I have not been using an audio interface program
>that supports the digital option. This choice is never displayed as part of
>the I/O.
>Robbie
>  
>
I own a SB Live card, and not an Audiophile 2496, but on the SB Live you 
use alsamixer to select all the recording sources. Then you run arecord 
and it records the sound from the multiple sources mixed together.

The problem with the SB Live is that recording from the SPDIF is always 
interpolated to 48kHz, some interpolation happens between 48Khz input 
and the 48Khz of the sound card. In reality the sound quality does not 
change, but it does cause problems if you are trying to capture an AC3 
or DTS signal, because the interpolation breaks it.

A good program to test recording in is arecord, which comes with alsa.

Cheers
James




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Audiophile 2496 S/PDIF Support

[Robert Robinson]

James,

Thank you.
I will try arecord.

Robbie

----- Original Message -----
From: "James Courtier-Dutton" <James@superbug.demon.co.uk>
To: "Robert Robinson" <robbiex@bellsouth.net>
Cc: "Takashi Iwai" <tiwai@suse.de>; <alsa-devel@lists.sourceforge.net>
Sent: Saturday, October 05, 2002 12:36 AM
Subject: Re: [Alsa-devel] Audiophile 2496 S/PDIF Support


> Robert Robinson wrote:
>
> >Takashi,
> >
> >I had communication from Kysela Jaroslav indicating that the Audiophile
2496
> >driver does support digital I/O.
> >The problem may be that I have not been using an audio interface program
> >that supports the digital option. This choice is never displayed as part
of
> >the I/O.
> >Robbie
> >
> >
> I own a SB Live card, and not an Audiophile 2496, but on the SB Live you
> use alsamixer to select all the recording sources. Then you run arecord
> and it records the sound from the multiple sources mixed together.
>
> The problem with the SB Live is that recording from the SPDIF is always
> interpolated to 48kHz, some interpolation happens between 48Khz input
> and the 48Khz of the sound card. In reality the sound quality does not
> change, but it does cause problems if you are trying to capture an AC3
> or DTS signal, because the interpolation breaks it.
>
> A good program to test recording in is arecord, which comes with alsa.
>
> Cheers
> James
>
>



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf