On Tue, 23.09.08 10:23, Alan Cox (alan@redhat.com) wrote:

> > In short: how modern software wants to drive a sound card has changed
> > quite a bit. And OSS3 is from the early 90's. So it's focussed on
> > hardware, and it is focussed on hw and sw from 20y ago. An SB16 is
> > quite different from a modern HDA sound card.
>
> Not vastly, its a DMA pipe with a DAC on the end

There's not necessarily a DAC at "the end" anymore. Could be SPDIF
too.

And if you say that a modern sound card behaves very similarly to early
90's sound card because it ues DMA, then you could say that sound card
is very similar to a harddisk, too. Which is definitely true in a way.

The really interesting part of audio is not the data transfer, it's
the timing. And that's where hardware changed. And software too. And
OSS is broken and legacy.

Lennart

--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, Sep 23, 2008 at 04:42:21PM +0200, Lennart Poettering wrote:
> > Not vastly, its a DMA pipe with a DAC on the end
>
> There's not necessarily a DAC at "the end" anymore. Could be SPDIF
> too.

SPDIF is over 20 years old too. There is a DAC somewhere and will be until
you get a copy protection jack and license slot embedded in your skull...

> the timing. And that's where hardware changed. And software too. And
> OSS is broken and legacy.

Not a lot - it started much like todays stuff, got all fancy and complicated
and is now back on the dumb end of the cycle with hardware raytraced sound
presumably going to be the next 'do it in hardware' cycle.

Alan

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, Sep 23, 2008 at 02:37:48PM +0200, Lennart Poettering wrote:
> I know. But ALSA hides that in a library, so you never have to deal
> with these ugly details. Ain't that great?

Depends on the library. In ALSA's case, it's a particularly badly
designed one, annoyingly enough. As an API, OSS is better.

OG.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, 23.09.08 17:40, Olivier Galibert (galibert@pobox.com) wrote:

> > I know. But ALSA hides that in a library, so you never have to deal
> > with these ugly details. Ain't that great?
>
> Depends on the library. In ALSA's case, it's a particularly badly
> designed one, annoyingly enough. As an API, OSS is better.

I know both APIs very very well. Probably much better than most
people. I have been using features of both APIs that apparently noone
ever used before me. PA probably uses a larger part of the ALSA API
than any other client. And from that experience I can say that while
ALSA has issues it certainly gets much much more right than OSS ever
did.

But anyway. We have to agree to disagree. This discussion is
pointless. Let's end this here.

Lennart

--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, 23.09.08 11:02, Alan Cox (alan@redhat.com) wrote:

> Not a lot - it started much like todays stuff, got all fancy and complicated
> and is now back on the dumb end of the cycle with hardware raytraced sound
> presumably going to be the next 'do it in hardware' cycle.

Still the timing model, which is the most interesting part is broken
and out-of-date in OSS.

Anyway, this discussion is pointless too. Let's end this.

Lennart

--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, 2008-09-23 at 15:02 +0200, Ralf Corsepius wrote:
> ioctl's are a well defined _low level_ interface, providing a clean and
> "natural" separation between kernel and userspace.

http://www.catb.org/esr/writings/taoup/html/ch20s03.html

> To make them easily applicable in high-level userspace applications,
> they are supposed to be wrapped.

That's just hiding the problem. Unfortunately, that's the best we can do
at the moment.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, 2008-09-23 at 15:02 +0200, Ralf Corsepius wrote:
> ioctl's are a well defined _low level_ interface, providing a clean and
> "natural" separation between kernel and userspace.

http://www.catb.org/esr/writings/taoup/html/ch20s03.html

> To make them easily applicable in high-level userspace applications,
> they are supposed to be wrapped.

That's just hiding the problem. Unfortunately, that's the best we can do
at the moment.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list