ALSA vs OSS: Some questions

ALSA vs OSS: Some questions

[Frank Barknecht]

Hallo,

I'm working on a Linux Audio article, where I also do provide a short
comparison of ALSA vs. OSS. For this, because I'm in no way a hardware
developer, I have some questions to make sure, I understand things
correctly. Would someone with deeper insight in the OSS/ALSA internals
help me and tell me, if the following assumptions are correct?

I read, that OSS was hard to extent, for example to write drivers for
modern hardware. Why is this so? 

Is it, because OSS ties its model of programming too close to the
hardware?

Paul Davis said in its LAD keynot, that in the past we only had OSS
and only had 16-bit interleaved stereo. From reading the OSS-developer
docs, it seemed to me, that OSS does support more formats than 16-bit
interl. stereo. So what can ALSA do in the format department, that OSS
couldn't do?

Can the ICE1712 chip server as an example for these difficulties? The
ICE chip doesn't support CD-quality music (44.1 samplerate, 16-bit,
stereo) in hardware, if I'm right? What format does it support? And
how does ALSA help in getting this supported compared to OSS (which
hasn't support for the ICE-cards)

Thank you very much for your answers and facts.

Regards,
-- 
 Frank Barknecht                               _ ______footils.org__


-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: ALSA vs OSS: Some questions

[Jaroslav Kysela]

On Mon, 7 Apr 2003, Frank Barknecht wrote:

> Hallo,
> 
> I'm working on a Linux Audio article, where I also do provide a short
> comparison of ALSA vs. OSS. For this, because I'm in no way a hardware
> developer, I have some questions to make sure, I understand things
> correctly. Would someone with deeper insight in the OSS/ALSA internals
> help me and tell me, if the following assumptions are correct?
> 
> I read, that OSS was hard to extent, for example to write drivers for
> modern hardware. Why is this so? 
> 
> Is it, because OSS ties its model of programming too close to the
> hardware?

The OSS's API was designed to support mainly cards which were available
mainly in middle of 90'. They supported mono and stereo interleaved data
in rates up to 48kHz with maximum sample width 16-bit.

> Paul Davis said in its LAD keynot, that in the past we only had OSS
> and only had 16-bit interleaved stereo. From reading the OSS-developer
> docs, it seemed to me, that OSS does support more formats than 16-bit
> interl. stereo. So what can ALSA do in the format department, that OSS
> couldn't do?

OSS can handle more formats, of course. But, the main difference between
ALSA and OSS is that OSS doesn't handle non-interleaved sample buffers at
all in the mmap mode. We can even handle some "complex" mmap modes like 4
stereo streams running together etc...

Interleaved buffers:

<offset0>ABABABAB

Non-interleaved buffers:

<offset0>AAAAA
<offset1>BBBBB

Complex (4 stereo streams etc.):

<offset0>ABABABAB
<offset1>CDCDCDCD
<offset2>EFEFEFEF
<offset3>GHGHGHGH

> Can the ICE1712 chip server as an example for these difficulties? The
> ICE chip doesn't support CD-quality music (44.1 samplerate, 16-bit,
> stereo) in hardware, if I'm right? What format does it support?

No, the ICE1712 chip supports rates from 32kHz to 96kHz including 44.1kHz.
The difference is that this chip (pro-part) supports only 32-bit little 
endian signed samples (in 24-bit resolution). So we need to convert 8-bit 
and 16-bit samples to this resolution (or from this resolution).

The better example is the RME9652 or HDSP drivers: They supports up to 26 
channels but only in the non-interleaved mode and 32-bit samples (same 
as ICE1712 - 24-bit resolution).

> And how does ALSA help in getting this supported compared to OSS (which
> hasn't support for the ICE-cards)

OSS does all conversions inside the kernel code. It's not much flexible
and also it's more sensitive for code errors.

We handle everything in the user space (alsa-lib). Our library does all 
necessary conversions and sample copying. Users can describe which 
conversions are wanted in the configuration files for this library. OSS 
does everything automatically.

						Jaroslav

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



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: ALSA vs OSS: Some questions

[Frank Barknecht]

Hallo Jaroslav,

thank you very much for your answers and explanations.

Greetings,
-- 
 Frank Barknecht                               _ ______footils.org__


-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: ALSA vs OSS: Some questions

[Frank Barknecht]

Hallo,

Jaroslav Kysela hat gesagt: // Jaroslav Kysela wrote:
> OSS can handle more formats, of course. But, the main difference
> between ALSA and OSS is that OSS doesn't handle non-interleaved
> sample buffers at all in the mmap mode. 

I got another question here: Am I right to assume, that mmap mode is
used, because it is the most efficient or is there hardware, that
requires mmapped access?

ciao
-- 
 Frank Barknecht                               _ ______footils.org__


-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: ALSA vs OSS: Some questions

[Jaroslav Kysela]

On Mon, 7 Apr 2003, Frank Barknecht wrote:

> Hallo,
> 
> Jaroslav Kysela hat gesagt: // Jaroslav Kysela wrote:
> > OSS can handle more formats, of course. But, the main difference
> > between ALSA and OSS is that OSS doesn't handle non-interleaved
> > sample buffers at all in the mmap mode. 
> 
> I got another question here: Am I right to assume, that mmap mode is
> used, because it is the most efficient or is there hardware, that
> requires mmapped access?

The difference between mmap and the standard read/write access is that we 
have only one copy of data between application and the kernel space (it's 
also called "zero-copy" sometimes).

r/w access (playback):

application -> local buffer -> write() -> driver -> copy data from user to 
DMA ring buffer (you have duplicated data in local buffer and DMA ring 
buffer)

mmap access (playback):

application -> copy data to mmaped DMA buffer -> notify driver that there 
are new data (using mmaped ring buffer pointer, so we don't need to cross 
the user space / kernel boundary at all)

Note: OSS API does not use the mmaped ring buffer pointers, too. It's 
ALSA's invention.

Note2: All ALSA's drivers are mmap capable (except GUS GF1 PCM, but I'll 
recode this driver as well).

Note3: the r/w access can be always emulated on top of the mmap access

						Jaroslav

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



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: ALSA vs OSS: Some questions

[James Courtier-Dutton]

Frank Barknecht wrote:

>Hallo,
>
>I'm working on a Linux Audio article, where I also do provide a short
>comparison of ALSA vs. OSS. For this, because I'm in no way a hardware
>developer, I have some questions to make sure, I understand things
>correctly. Would someone with deeper insight in the OSS/ALSA internals
>help me and tell me, if the following assumptions are correct?
>
>I read, that OSS was hard to extent, for example to write drivers for
>modern hardware. Why is this so? 
>
>Is it, because OSS ties its model of programming too close to the
>hardware?
>
>Paul Davis said in its LAD keynot, that in the past we only had OSS
>and only had 16-bit interleaved stereo. From reading the OSS-developer
>docs, it seemed to me, that OSS does support more formats than 16-bit
>interl. stereo. So what can ALSA do in the format department, that OSS
>couldn't do?
>
>Can the ICE1712 chip server as an example for these difficulties? The
>ICE chip doesn't support CD-quality music (44.1 samplerate, 16-bit,
>stereo) in hardware, if I'm right? What format does it support? And
>how does ALSA help in getting this supported compared to OSS (which
>hasn't support for the ICE-cards)
>
>Thank you very much for your answers and facts.
>
>Regards,
>  
>
As an application developer, one of the main advantages of alsa is that 
all sound cards are supported with the entire alsa-lib api being valid 
and useable.
With OSS, different sound cards support different, so called optional, 
parts of the OSS specification. The problem is that as digital audio 
technology has advanced, more sample rates, multimedia requiring 
audio/video sync etc. applications need these optional OSS functions, 
but the application cannot be sure that all sound cards will perform as 
expected.
An example of this difference: -
alsa supports fully multi threaded audio applications.
some OSS drivers support it, some OSS drivers do not but there is no way 
for the multi-threaded audio application to tell.
So if the OSS driver supports multi-threading, no problems, but if the 
OSS driver does not, your application crashes!

 ALSA does have a major advantage over OSS, and that is that a lot of 
the code is shared between all the different sound cards. So, when one 
implements support for a new sound card, one can be fairly sure that is 
will function well, because only a small amount of hardware specific 
code has to be written. So if some new feature is added to the alsa-lib 
api, all sound cards automatically benefit from it. With OSS, each sound 
card has it's own driver code, without any shared code.

When ALSA detects that a sound card does not have a requested feature. 
E.g. Audio application wants 44.1khz but the sound card does not have 
it, ALSA can take several approaches.
1) snd_pcm_hw_params_set_rate() - on the hw interface : Deny the request 
forcing the application to try another rate and forcing the application 
to do sample rate conversion.
2) snd_pcm_hw_params_set_rate_near() - on the hw interface: Select a 
sample rate that it can do that is close to what the application wants 
and force the application to do sample rate conversion.
3) snd_pcm_hw_params_set_rate() - on the plug interface: Accept the 
request, and get ALSA to do all the sample rate conversion necessary.

OSS can only do (1).

Another nice thing about ALSA is that it's API is with friendly function 
calls.
OSS just uses IOCTL calls.

OSS has particularly bad api when it comes to multiple audio channels.
In ALSA you can open up 5 interleaved channels for audio and also decide 
which audio channel reaches which speaker.
For example, We might have 2 front, 2 rear and 1 center speaker
or 2 front, 2 rear and 1 subwoofer.
The user might have 6 speakers connected. 2 front, 2 rear and center and 
subwoofer.
So, with OSS you can select 5 interleaved channels, but you would have 
no idea where the 5th channel would come out of.
With OSS you would have to select 6-interleaved channels and get the 
application to move the data around to get the the data in the correct 
channls.

Cheers
James




-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: ALSA vs OSS: Some questions

[Frank Barknecht]

Hallo James,

James Courtier-Dutton hat gesagt: // James Courtier-Dutton wrote:

> As an application developer, one of the main advantages of alsa is that 
> all sound cards are supported with the entire alsa-lib api being valid 
> and useable.
> [...]

Thank you for this detailed point of view. I guess, I also can use
several of these real world examples to make the advantages of ALSA
clearer to a non-developer audience (like I am...)

ciao
-- 
 Frank Barknecht                               _ ______footils.org__


-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/