Re: [linux-audio-dev] ALSA vs OSS/free

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] ALSA vs OSS/free
From: Jussi Laako (jussi.laako_AT_kolumbus.fi)
Date: Sun Mar 10 2002 - 15:50:37 EET


Paul Davis wrote:
>
> but linus has announced that they want such code removed from the
> kernel. only the pending arrival of ALSA has stopped this from happening.

ALSA is not part of 2.4.x, so who cares?
Nothing stops people from writing kind of kernel modules they like.

I think most of the drivers should be taken out of the kernel tree to allow
more flexible updates and to reduce kernel source tree bloat.

> OSS does not do s/w mixing for any devices that i know of. it supports
> multi-open, just like ALSA, for all h/w that supports it, where the
> means of doing so has been described by the h/w maker.

It does, here's output from /dev/sndstat of my laptop (devices 2-9 do
samplerate/format conversion & software mixing):

OSS/Linux 3.9.6b (C) 4Front Technologies 1996-2002

License serial number: XXXXXXXXX
Options: APCI MIXAPCI MIX VORTEX
This copy of OSS is licensed to Jussi Laako

Build: 2.4.18

Card config:
Yamaha OPL3-SAx at 0x530 irq 5 drq 1,0
OPL-2/OPL-3 FM at 0x388
Software mixing (audio)

Audio devices:
0: MSS audio codec (CS4231) (DUPLEX)
1: Shadow of audio device #0 (DUPLEX)
2: SoftOSS v2.0 Playback CH #0 (GRC2)
3: SoftOSS v2.0 Playback CH #1 (GRC2)
4: SoftOSS v2.0 Playback CH #2 (GRC2)
5: SoftOSS v2.0 Playback CH #3 (GRC2)
6: SoftOSS v2.0 Playback CH #4 (GRC2)
7: SoftOSS v2.0 Playback CH #5 (GRC2)
8: SoftOSS v2.0 Playback CH #6 (GRC2)
9: SoftOSS v2.0 Playback CH #7 (GRC2)

Synth devices:
0: Yamaha OPL-3
1: SoftOSS v2.0

Midi devices:

Timers:
0: System clock
1: MSS audio codec (CS4231)

Mixers:
0: MSS audio codec (CS4231)
1: SoftOSS

> OSS has ZERO support for non-interleaved cards. there's no way to even
> express the idea of it in OSS. is this some kind of competition?

Driver can always interleave the data from non-interleaved format. That's
piece of cake. One for-loop.

Problem is that I don't know how to get the 24-bit data out of ALSA. Only
16-bits works for me. Asking for 24-bit format works, but crashes libasound.

> you're probably on a sourceforge dialup blacklist. it happened to me a
> few weeks ago. i checked out why it was happening. sf.net won't accept

Now it seems to work again.

> of course, if you want to find out how many channels the device has,
> OSS can't help you (except by returning -EINVAL to an attempt to set
> it).

Just set it to something like 8 and see value returned in channel count.

> if you want to change when the kernel will wake up your process
> thats sleeping on poll or select, OSS can't help you. if you want

I don't use select(), but setting the fragment size should change the
threshold, as select() should return when there is full fragment available
for reading or writing.

> control what the driver does if there is an xrun, OSS can't help
> you. and if you want to control standard digital audio controls, like

Application should do that. Just check the over/underrun values in
audio_errinfo (SNDCTL_DSP_GETERROR).

> clock source or IEC958 configuration, OSS can't help with that either
> unless you want to write code specific for each different h/w device.

What is IEC958?

> the point of an API is to make the easy things as easy as possible
> while making the hard things possible. OSS makes the easy things very
> easy, but doesn't allow the hard things at all. ALSA makes the easy
> things easy, and allows for all the hard things that anyone has
> brought up so far.

That's not bad. ALSA could also make comedi obsolete if designed correctly
and that would be great as I find it annoying that I have to support N+1
different APIs for different hardware. Now I have support for five different
APIs (OSS, ALSA05, ALSA09, comedi, ASIO2 (win32)), not to even count the
vendor specific DAQ APIs.

To obsolete comedi, is there way in ALSA to do digital I/O (reading and
writing bits in digital interfaces using values & masks)?
Is there way to configure gains per channel, channel scan sequences, per
channel filter parameters and such?

My point here is that if we have complex API, then it should be able to do
all the complex things. I'm not going to call ALSA simple.

> Then why don't you fix up your email routing and join alsa-devel to
> tell us about your experiences and maybe we can fix it.

I'm not going to change my server configuration for some list, but now it
seems to work again so no problem with this anymore.

> Not much of ALSA is documented at this time. Feel free to volunteer to
> help with the effort.

I'm fulltime working with other things (like writing applications that use
ALSA and OSS) so I don't have time to do it. It's also pretty hard to write
documentation when there is no documentation as I didn't write the code...
:)

> So where do you think interleaving and deinterleaving should be? How
> about support for floating point format? What about handling of

Interleaving and deinterleaving should be in driver modules. Same thing for
floating point format.

> multiple process access to the same device? What about support for
> implementing "subset" devices (e.g. 12 stereo devices mapped to a 24
> channel card)? Should they be in the kernel?

Yes, what is the problem here? It's just matter of copying data to correct
place. One for-loop again.

Here are my devices (/dev/sndstat of desktop):

0: CMedia CM8738 (rev 37) (DUPLEX)
1: CMedia CM8738 (playback only) (DUPLEX)
2: Ensoniq AudioPCI97 (ES1371) (DUPLEX)
3: Ensoniq AudioPCI97 (ES1371) (playback only)
4: M Audio Delta 1010 out1/2
5: M Audio Delta 1010 out3/4
6: M Audio Delta 1010 out5/6
7: M Audio Delta 1010 out7/8
8: M Audio Delta 1010 S/PDIF out
9: M Audio Delta 1010 in1/2
10: M Audio Delta 1010 in3/4
11: M Audio Delta 1010 in5/6
12: M Audio Delta 1010 in7/8
13: M Audio Delta 1010 S/PDIF in
14: M Audio Delta 1010 input from mon. mixer
15: M Audio Delta 1010 (all outputs)
16: M Audio Delta 1010 (all inputs)

> OK, so you want to rewrite Linux. That has nothing to do with ALSA.

It doesn't need any rewrite because all can be done using kernel modules.

> as erik mentioned, user-space device drivers appear to be coming to
> linux bit by bit. we don't know enough about them yet to really
> understand how good of an idea they are at this point.

Linux is becoming more and more microkernel'ish and I believe it's good
trend.

> I spend too much of my time working on Linux device drivers to be
> wasting any more on drivers for an operating system that almost nobody
> will use. Sorry.

I don't think RT-Linux and RT-AI as different operating systems. Only as
realtime extensions to Linux kernel that could be included in standard
kernel.

> Abramo and I once sketched out how to write ASIO on top of alsa-lib.
> However, JACK is even simpler than ASIO, and it already exists (insert
> ob. rant about CVS access here).

I would like to see bufferswitch callback directly called from the interrupt
handler.

        - Jussi Laako

-- 
PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B  39DD A4DE 63EB C216 1E4B
Available at PGP keyservers


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun Mar 10 2002 - 15:41:35 EET