Mailing List Archive

Robert Hancock <hancockr <at> shaw.ca> writes:

> In the case of S/PDIF output on ice1724 (and probably other cards), it
> would be nice if ALSA defaulted to routing default audio to both the
> S/PDIF and analog ports, as this is what most users would normally
> expect.. The Windows drivers work like that, but on Linux you have to
> pick one or the other (at least without a bunch of mucking with the
> config file).

I believe some cards can't do this in fact which might be argument due to
consistency. Otherwise I don't so much have an opinion on whether or not this
should be default though...

Rene




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Friday 29 June 2007, Miklos Szeredi wrote:
> > > > Not as if it would be hard to add ioctl support to fuse. What fuse
> > > > can't handle is the data argument of ioctl(), so the most it could do
> > > > is give the filesystem a pid (tid) and a virtual address. The
> > > > userspace fs could then get/put the data through /proc/<pid>/mem.
> > >
> > > Hork...
> > >
> > > Identify the generic ioctls that are relevant to a FUSE file system and
> > > have real meaning *and* are useful.
> >
> > I don't think there are any such.
> >
> > The point in this thread was I think about emulating an OSS sound
> > device through a fuse fs. In that case fuse would need _generic_
> > ioctl support, which simply can't be done without weird userspace
> > hacks.
>
> Well, had a look at what FUSD does. It assumes that the ioctl
> argument is stuctured according to the command. If all OSS ioctls are
> like that, then fine, fuse can support it properly.
>
> The drawback of this is that ioctls which aren't structured properly
> could cause weird failures due to wrong data being accessed by the
> poor unknowing kernel.
>
> Miklos

Included with the docs there's a list of the OSS ioctls. I don't understand
enough of the problem to judge whether they are suitable to be handled by
FUSE:

http://manuals.opensound.com/developer/ioctl.html [version 4]
http://www.4front-tech.com/pguide/oss.pdf [version 3]

I don't know which API version is supposed to be supported though.

Regards,
Flo

--
Palimm Palimm!
http://tapas.affenbande.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

> > Well, had a look at what FUSD does. It assumes that the ioctl
> > argument is stuctured according to the command. If all OSS ioctls are
> > like that, then fine, fuse can support it properly.
> >
> > The drawback of this is that ioctls which aren't structured properly
> > could cause weird failures due to wrong data being accessed by the
> > poor unknowing kernel.
>
> Included with the docs there's a list of the OSS ioctls. I don't understand
> enough of the problem to judge whether they are suitable to be handled by
> FUSE:
>
> http://manuals.opensound.com/developer/ioctl.html [version 4]
> http://www.4front-tech.com/pguide/oss.pdf [version 3]
>
> I don't know which API version is supposed to be supported though.

Thanks, but these docs are about what the ioctls do, and I'm totally
uninterested in that. What I'm interested is how the ioctl data is
_structured_.

OK, had a look at <linux/soundcard.h>, it does define a data
structuring based on the ioctl numbers, and it's just slightly
different from the structuring defined by <asm-generic/ioctl.h>. Oh,
the beauty of the ioctls.

So answering my own question: no, it's not sanely possible to support
ioctls through fuse without userspace hacks or significant effort.

A possibly acceptable option is to add a plugin mechanism, whereby
people could write small ioctl interpreter kernel modules for their
specific needs (such as parsing OSS ioctls), which would
serialize/deserialize any type of ioctl input/output making them
suitable for transfering between the kernel and the userspace
filesystem.

Another, much more complex option is to design a generic ioctl data
interpreter language, and let the filesystem upload their ioctl
parsers into the kernel.

Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Tomasz K³oczko wrote:
>
> Few dayas ago OSS source code was oppened uder CDDL for Solaris and
> GLPv2 for Linux:
>
> http://www.opensound.com/press/2007/oss-gpl-cddl.txt
>
> So this source without problems code can be integragrated in Linus
> tree and after this Linux can provide much better soud supoport than
> with current ALSA.
>
> Any plans for doing this ?
>
> kloczek

I know this may sound kind of stupid, but how about not deprecating
either, and fully supporting both sound systems? Maybe we can get them
to work together, and the distro or user can choose whether they would
like to use alsa or oss for that particular card (or have the distro
choose the sound drivers that are best supported for that particular
card). As it is now, most apps already support oss and alsa.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote:
>
> I know this may sound kind of stupid, but how about not deprecating either,
> and fully supporting both sound systems? Maybe we can get them to work
> together, and the distro or user can choose whether they would like to use
> alsa or oss for that particular card (or have the distro choose the sound
> drivers that are best supported for that particular card). As it is now,
> most apps already support oss and alsa.

It does not sound stupid and sounds good at first sight.

But there are problems we've already seen with similar situations in
different parts of the kernel:

They would have different hardware support, features and bugs.

And then a user user whose sound card is only supported by sound system A
needs a feature only available in sound system B.

And the quality decreases since people will often not report bugs in
sound system A if sound system B works for them.

OTOH, for a user it shouldn't matter whether there's OSS or ALSA, that's
mostly a difference for application developers. And since (as you say)
most applications already support both, there's no compelling reason for
providing more than one of them.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Wed, 4 Jul 2007, Adrian Bunk wrote:

> On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote:
>>
>> I know this may sound kind of stupid, but how about not deprecating either,
>> and fully supporting both sound systems? Maybe we can get them to work
>> together, and the distro or user can choose whether they would like to use
>> alsa or oss for that particular card (or have the distro choose the sound
>> drivers that are best supported for that particular card). As it is now,
>> most apps already support oss and alsa.
>
> It does not sound stupid and sounds good at first sight.
>
> But there are problems we've already seen with similar situations in
> different parts of the kernel:
>
> They would have different hardware support, features and bugs.
>
> And then a user user whose sound card is only supported by sound system A
> needs a feature only available in sound system B.
>
> And the quality decreases since people will often not report bugs in
> sound system A if sound system B works for them.
>
> OTOH, for a user it shouldn't matter whether there's OSS or ALSA, that's
> mostly a difference for application developers. And since (as you say)
> most applications already support both, there's no compelling reason for
> providing more than one of them.

From Hannu message:
"I think the ideal solution would be that both ALSA and OSS APIs can
co-exist by sharing the same low level drivers (which has
already been demonstrated). The low level driver interfaces in both
systems are practically identical. This means that ALSA's
core can work with OSS' drivers and vice versa."

So Hannu have plan for share ALSA low level drivers without changes
(porting to OSS will not be neccessary and/or will need only small
amount of time .. IMO much less than make ALSA fully functional).
Main diffrences between ALSA and OSS are above low level drivers so IMO it
is completly possible have ALSA and OSS in the same tree.
OSS wtil not dies (and try resurect) ALSA still (after few years) was not
born and still isn't rock solid point odf Linux desktop (IMO it is most
weeknes ponit of LD). IMO it will be better if Hannu will start pushing
any OSS chages to Linus tree. Current OSS code in Linus tree is more or
less not useable so allow maintain this code in main tree can't hurd
anything outside this area.

kloczek
--
-----------------------------------------------------------
*Ludzie nie maj± problemów, tylko sobie sami je stwarzaj±*
-----------------------------------------------------------
Tomasz K³oczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

On Wed, 4 Jul 2007 19:32:29 +0200, Adrian Bunk wrote:
> On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote:
>>
>> I know this may sound kind of stupid, but how about not deprecating either,
>> and fully supporting both sound systems? Maybe we can get them to work
>> together, and the distro or user can choose whether they would like to use
>> alsa or oss for that particular card (or have the distro choose the sound
>> drivers that are best supported for that particular card). As it is now,
>> most apps already support oss and alsa.
>
> It does not sound stupid and sounds good at first sight.
>
> But there are problems we've already seen with similar situations in
> different parts of the kernel:
> They would have different hardware support, features and bugs.
>
> And then a user user whose sound card is only supported by sound system A
> needs a feature only available in sound system B.
>
> And the quality decreases since people will often not report bugs in
> sound system A if sound system B works for them.
>
> OTOH, for a user it shouldn't matter whether there's OSS or ALSA, that's
> mostly a difference for application developers. And since (as you say)
> most applications already support both, there's no compelling reason for
> providing more than one of them.
>
> cu
> Adrian
>

If the developers of ALSA made a nuclear reactor, it would have five
different control panels for controlling the rods in the reactor core, and
each would do something different and not what the documentation said.

Actually, I lied about that. It wouldn't have any usable documentation.
But, there would be a hidden feature that you could sound the overload
alarm by pulling out the stapler in the control office. Useful feature,
that.

As an audio developer on Linux, I must say that developing with ALSA is
absolute fucking hell. If there was a way where both APIs could natively
be supported, more people would be happy with the current state of affairs
in the kernel.

The most fucked up thing that I can think of about the current state of
affairs in ALSA is dmix. Every other UNIX sound system like ALSA does it's
software mixing in kernel space. The applications never even know about
it. It's not only until recently (2005-2006 or so) that ALSA came close to
this, but there are still problems. Many cards need workarounds to make
dmix work because of the way it works, and the way that ALSA buffers data
around.

For the non-technically inclined, ALSA only keeps two fragments for
input/output data each. This is horribly unusable because most soundcard
fragments are only 1KB, so applications have to adopt ringbuffers to pass
data to ALSA. If you're doing video, this leads to possible timing issues
unless you sit down and well design your abstraction layer for audio I/O.

So people switch to things like JACK and PulseAudio because it's the only
way they can get workable Audio I/O on ALSA.

What's even worse for the ALSA API is that it's designed around lowlatency
programming, but only a few drivers properly support it. Why do you need
lowlatency access to play a beep or a ding or whatever? The simple answer
is you don't.

ALSA could and can be done correctly, but OSS4 is already here and
provides an API which solves all of ALSA's current problems. So why waste
time with that, when OSS4 is already here and more friendly to the
developers of the software most Linux users use?

If OSS4 and ALSA apis could run on the same base driver, then a lot more
people will be happier, as there will be choice available in which API to
use, e.g. OSS4 or the libasound self-abuse method.

Hannu has ideas on how that could work. I suggest all of the kernel
developers listen, and listen well, or this mess will never be fixed in a
way that is truly usable.

-nenolod
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, Jul 07, 2007 at 02:41:05AM +0000, William Pitcock wrote:
> The most fucked up thing that I can think of about the current state of
> affairs in ALSA is dmix. Every other UNIX sound system like ALSA does it's
> software mixing in kernel space. The applications never even know about
> it. It's not only until recently (2005-2006 or so) that ALSA came close to
> this, but there are still problems. Many cards need workarounds to make
> dmix work because of the way it works, and the way that ALSA buffers data
> around.

I have to agree. I am not an audio programmer, just a user; but the
bottom line is simply: It is WAY to hard to get things working (if
at all possible).
At one point I tried to get sound from xmms and ut2004 at the same time
(on my new machine). I was ASTONISHED that it didn't Just-Work!
After trying many complex things-- I gave up and put my old
soundblaster Live! in the new PC - because that card has hardware
support for this. Now I was lucky to HAVE that other soundcard,
but what about all those other users out there who just buy a new
PC, with a sound chip on the motherboard and then, being simple, ordinairy
users, have to face this ALSA configuration hell to do something
as simple as having two audio applications play sound at the same time?

> For the non-technically inclined, ALSA only keeps two fragments for
> input/output data each. This is horribly unusable because most soundcard
> fragments are only 1KB, so applications have to adopt ringbuffers to pass
> data to ALSA. If you're doing video, this leads to possible timing issues
> unless you sit down and well design your abstraction layer for audio I/O.

Worse-- the two fragment limit is passed on to the OSS emulation (or at least
it was in 2005; but if this is still true for the ALSA API in 2007, then my
guess is that it's also still true for the OSS emulation). The result is
that applications written for OSS do not work anymore when using the OSS
emulation of ALSA and therefore the argument of providing backwards
compatibility doesn't exist.

...snip...
> Hannu has ideas on how that could work. I suggest all of the kernel
> developers listen, and listen well, or this mess will never be fixed in a
> way that is truly usable.
>
> -nenolod

Good post, nenolod.

--
Carlo Wood <carlo@alinoe.com>

PS I am NOT saying that I want ALSA to be removed from the kernel.
I am just saying that I agree with those who think that the
ALSA API is too complex, hard to use and has serious flaws that
should be addressed.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/