Re: [2.6 patch] schedule obsolete OSS drivers for removal

Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Thorsten Knabe]

On Tue, 26 Jul 2005, Adrian Bunk wrote:

> This patch schedules obsolete OSS drivers (with ALSA drivers that
> support the same hardware) for removal.

Hello Adrian.

I'm the maintainer of the OSS AD1816 sound driver. I'm aware of two 
problems of the ALSA AD1816 driver, that do not show up with the OSS 
driver:
- According to my own experience and user reports audio is choppy with 
some VoIP Softphones like gnophone at least when used with the ALSA OSS 
emulation layer, whereas the OSS driver is crystal clear.
- Users reported, that on some HP Kayak systems the on-board AD1816A 
was not properly detected by the ALSA driver or was detected, but 
there was no audio output. I'm not sure if the problem is still present in 
the current ALSA driver, as I do not own such a system.

Maybe the OSS driver should stay in the kernel, until those problems are 
fixed in the ALSA driver.

Regards
Thorsten

-- 
___
  |        | /                 E-Mail: linux@thorsten-knabe.de
  |horsten |/\nabe                WWW: http://linux.thorsten-knabe.de


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Adrian Bunk]

On Thu, Jul 28, 2005 at 05:04:20PM +0200, Thorsten Knabe wrote:
> On Tue, 26 Jul 2005, Adrian Bunk wrote:
> 
> >This patch schedules obsolete OSS drivers (with ALSA drivers that
> >support the same hardware) for removal.
> 
> Hello Adrian.

Hi Thorsten,

> I'm the maintainer of the OSS AD1816 sound driver. I'm aware of two 
> problems of the ALSA AD1816 driver, that do not show up with the OSS 
> driver:
> - According to my own experience and user reports audio is choppy with 
> some VoIP Softphones like gnophone at least when used with the ALSA OSS 
> emulation layer, whereas the OSS driver is crystal clear.
> - Users reported, that on some HP Kayak systems the on-board AD1816A 
> was not properly detected by the ALSA driver or was detected, but 
> there was no audio output. I'm not sure if the problem is still present in 
> the current ALSA driver, as I do not own such a system.
> 
> Maybe the OSS driver should stay in the kernel, until those problems are 
> fixed in the ALSA driver.

thanks for this note, I'll drop the AD1816 driver from my list.

> Regards
> Thorsten

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



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Lee Revell]

On Thu, 2005-07-28 at 17:04 +0200, Thorsten Knabe wrote:
> I'm the maintainer of the OSS AD1816 sound driver. I'm aware of two 
> problems of the ALSA AD1816 driver, that do not show up with the OSS 
> driver:
> - According to my own experience and user reports audio is choppy with 
> some VoIP Softphones like gnophone at least when used with the ALSA OSS 
> emulation layer, whereas the OSS driver is crystal clear.
> - Users reported, that on some HP Kayak systems the on-board AD1816A 
> was not properly detected by the ALSA driver or was detected, but 
> there was no audio output. I'm not sure if the problem is still present in 
> the current ALSA driver, as I do not own such a system.

What are the bug id #s in the ALSA BTS?  If it's not in the bug tracker
it's never going to get fixed.

Lee



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Jaroslav Kysela]

On Thu, 28 Jul 2005, Thorsten Knabe wrote:

> On Tue, 26 Jul 2005, Adrian Bunk wrote:
> 
> > This patch schedules obsolete OSS drivers (with ALSA drivers that
> > support the same hardware) for removal.
> 
> Hello Adrian.
> 
> I'm the maintainer of the OSS AD1816 sound driver. I'm aware of two 
> problems of the ALSA AD1816 driver, that do not show up with the OSS 
> driver:
> - According to my own experience and user reports audio is choppy with 
>   some VoIP Softphones like gnophone at least when used with the ALSA 
>   OSS emulation layer, whereas the OSS driver is crystal clear.
> - Users reported, that on some HP Kayak systems the on-board AD1816A was 
>   not properly detected by the ALSA driver or was detected, but there 
>   was no audio output. I'm not sure if the problem is still present in 
>   the current ALSA driver, as I do not own such a system.
> 
> Maybe the OSS driver should stay in the kernel, until those problems are 
> fixed in the ALSA driver.

The problem is that nobody reported us mentioned problems. We have no 
bug-report regarding the AD1816A driver. Perhaps, it would be a good idea 
to add a notice to the help file and/or driver that the ALSA driver should 
be tested and bugs reported to the ALSA bug-tracking-system.

					Thanks,
						Jaroslav

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Adrian Bunk]

On Fri, Jul 29, 2005 at 08:52:45AM +0200, Jaroslav Kysela wrote:
> 
> The problem is that nobody reported us mentioned problems. We have no 
> bug-report regarding the AD1816A driver. Perhaps, it would be a good idea 
> to add a notice to the help file and/or driver that the ALSA driver should 
> be tested and bugs reported to the ALSA bug-tracking-system.

Although it wouldn't have helped with this driver, could you review the 
currently 35 open ALSA bugs in the kernel Bugzilla [1]?

- Some might first require a question to the submitter whether the
  problem is still present in recent kernels.
- Some might be problems in other parts of the kernel
  (e.g. ACPI interrupt configuration problems).
- But some bugs might be bugs still present in recent ALSA.

The Gentoo people are using a pretty easy and nice way for forwarding 
their bugs to the kernel Bugzilla, that would work the following way for 
forwarding Bugs from the kernel Bugzilla to the ALSA BTS:
- open a new bug in the ALSA BTS:
  - short description of the issue
  - more information is at 
      http://bugzilla.kernel.org/show_bug.cgi?id=12345
- add a comment to the kernel Bugzilla (but leave the bug open):
    this bug is now handled at the ALSA BTS at 
    https://bugtrack.alsa-project.org/alsa-bug/view.php?id=23456

You could also do this the other way round if e.g. a ACPI interrupt 
configuration problem was reported to the ALSA BTS.

> 					Thanks,
> 						Jaroslav

cu
Adrian

[1] http://bugzilla.kernel.org/

-- 

       "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



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Thorsten Knabe]

On Fri, 29 Jul 2005, Jaroslav Kysela wrote:

> On Thu, 28 Jul 2005, Thorsten Knabe wrote:
>
>> On Tue, 26 Jul 2005, Adrian Bunk wrote:
>>
>>> This patch schedules obsolete OSS drivers (with ALSA drivers that
>>> support the same hardware) for removal.
>>
>> Hello Adrian.
>>
>> I'm the maintainer of the OSS AD1816 sound driver. I'm aware of two
>> problems of the ALSA AD1816 driver, that do not show up with the OSS
>> driver:
>> - According to my own experience and user reports audio is choppy with
>>   some VoIP Softphones like gnophone at least when used with the ALSA
>>   OSS emulation layer, whereas the OSS driver is crystal clear.
>> - Users reported, that on some HP Kayak systems the on-board AD1816A was
>>   not properly detected by the ALSA driver or was detected, but there
>>   was no audio output. I'm not sure if the problem is still present in
>>   the current ALSA driver, as I do not own such a system.
>>
>> Maybe the OSS driver should stay in the kernel, until those problems are
>> fixed in the ALSA driver.
>
> The problem is that nobody reported us mentioned problems. We have no
> bug-report regarding the AD1816A driver. Perhaps, it would be a good idea
> to add a notice to the help file and/or driver that the ALSA driver should
> be tested and bugs reported to the ALSA bug-tracking-system.

Hello Jaroslav.

I'll do some testing during the upcoming weekend to confirm, that the 
mentioned problems still exist with the current ALSA release. Last time I 
checked was sometime around Linux 2.6.10. I'll file a bug report of my 
findings to the ALSA bug tracking system and contact the author of the 
driver. Initially I had not spent much time on those problems, because I 
had an alternative working OSS driver, but since removal of the OSS seems 
to get closer, it's probably time to fix these issues now.

Regards
Thorsten

-- 
___
  |        | /                 E-Mail: linux@thorsten-knabe.de
  |horsten |/\nabe                WWW: http://linux.thorsten-knabe.de


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: [2.6 patch] schedule obsolete OSS drivers for removal

[James Courtier-Dutton]

Adrian Bunk wrote:
> This patch schedules obsolete OSS drivers (with ALSA drivers that 
> support the same hardware) for removal.
> 
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
> 
> ---
> 
> I've Cc'ed the people listed in MAINTAINERS as being responsible for one 
> or more of these drivers, and I've also Cc'ed the ALSA people.
> 

I am happy for the emu10k1 OSS driver to go.
The ALSA driver has considerably more features now.

James



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Peter Zubaj]

Hi,

I think many of sb live and emu10k1 driver will not like alsa sb live
mixer.

Peter Zubaj



___________________________________________________________________________
Podte na navstevu k Wande - k najlepsej priatelke kazdej zeny na internete.
http://www.wanda.sk/



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click

Re: Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Adrian Bunk]

On Fri, Jul 29, 2005 at 05:58:18PM +0200, Thorsten Knabe wrote:
> 
> Hello Jaroslav.
> 
> I'll do some testing during the upcoming weekend to confirm, that the 
> mentioned problems still exist with the current ALSA release. Last time I 
> checked was sometime around Linux 2.6.10. I'll file a bug report of my 
> findings to the ALSA bug tracking system and contact the author of the 
> driver. Initially I had not spent much time on those problems, because I 
> had an alternative working OSS driver, but since removal of the OSS seems 
> to get closer, it's probably time to fix these issues now.

Thanks a lot!

Can you send me the bug numbers in the ALSA bug tracking system if you 
have to send bug reports, so that I can track when these issues will be 
resolved?

> Regards
> Thorsten

TIA
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



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Andrew Haninger]

On 7/31/05, Adrian Bunk <bunk@stusta.de> wrote:
> Can you send me the bug numbers in the ALSA bug tracking system if you
> have to send bug reports, so that I can track when these issues will be
> resolved?
Thorsten: Please remember to include the list(s) when emailing those
links/numbers. I'd like to be able to watch it, too, and add any
information that I can, rather than entering a duplicate bug.

Thanks.

-Andy


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click

Re: Re: [2.6 patch] schedule obsolete OSS drivers for removal

[James Courtier-Dutton]

Thorsten Knabe wrote:

> On Mon, 1 Aug 2005, Andrew Haninger wrote:
>
>> Thorsten: Please remember to include the list(s) when emailing those
>> links/numbers. I'd like to be able to watch it, too, and add any
>> information that I can, rather than entering a duplicate bug.
>
>
> Hello.
>
> I have taken a closer look at the ALSA AD1816 sound driver during the 
> last weekend. Here are my findings:
>
> On vanilla Linux 2.6.12.3 and 2.6.13-rc4 modprobe hangs in D-state 
> when loading the snd-ad1816a module. No messages have been logged to 
> the syslog and the system is otherwise stable. Of course the sound 
> card is unusable.
> On Linux 2.6.8 (as shipped with current Debian Sarge), vanilla Linux 
> 2.6.10 and Linux 2.6.11.12 the module loads fine.
>
> I have done some tests with xmms(Debian), kphone(VoIP-Phone/Debian) 
> and iaxcomm(VoIP-Phone/self-made). Audio playback with xmms is always 
> fine using either ALSA or OSS emulation. Using OSS emulation with one 
> of the VoIP phones, playback and recording stop a few seconds after 
> the call is started. Using the ALSA interface with kphone works, but 
> there is a continuous clicking approximately 3 times per second. Also 
> audio latency is poor compared to the OSS driver. iaxcomm does not 
> support the ALSA audio interface, thus no problems here. :-)
> The native OSS driver is fine on all kernels with all tested 
> applications.
>
> Also the ALSA driver does not have an equivalent for the 
> "ad1816_clockfreq" option of the OSS driver. The AD1816 chip requires 
> a 33MHz reference clock, however some cards use a different (mostly 
> 32.125MHz) clock, thus the audio sample rate has to be corrected 
> before it is written to the hardware registers for proper playback and 
> recording speed.
>
> I have not filed any bug reports to the ALSA bug tracking system so 
> far, but will do so tomorrow and add the corresponding bug numbers to 
> this thread.
>
> Thorsten
>
It sounds to me that the best way to fix this is either:
a) Detect sound card subversion number and select different clock based 
on that.
b) Some how auto detect the clock, much like the intel8x0 driver does.
c) Provide a manual option like the OSS driver. (We should probably have 
this as well as (a) for the cases where (a) does not know about 
particular soundcard X yet.

James



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Thorsten Knabe]

Hello.

Here are the bug id's for the various issues from the ALSA bugtracking 
system:

On Tue, 2 Aug 2005, Thorsten Knabe wrote:
> On vanilla Linux 2.6.12.3 and 2.6.13-rc4 modprobe hangs in D-state when 
> loading the snd-ad1816a module. No messages have been logged to the syslog 
> and the system is otherwise stable. Of course the sound card is unusable.

#1300: modprobe goes into D-state when inserting snd-ad1816a

> Using OSS emulation with one of the VoIP 
> phones, playback and recording stop a few seconds after the call is started. 
> Using the ALSA interface with kphone works, but there is a continuous 
> clicking approximately 3 times per second. Also audio latency is poor 
> compared to the OSS driver.

#1301: Kernel OSS emulation stops working after a few seconds when used 
with VoIP softphones

#1302: Clicking noise when using kphone with the ALSA AD1816A sound driver

> Also the ALSA driver does not have an equivalent for the "ad1816_clockfreq" 
> option of the OSS driver.

#1303: AD1816A sound driver has no parameter to adjust reference clock 
frequency

Regards
Thorsten

-- 
___
  |        | /                 E-Mail: linux@thorsten-knabe.de
  |horsten |/\nabe                WWW: http://linux.thorsten-knabe.de


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Adrian Bunk]

On Thu, Jul 28, 2005 at 03:43:49PM +0200, Jaroslav Kysela wrote:
> On Thu, 28 Jul 2005, Alan Cox wrote:
> 
> > On Mer, 2005-07-27 at 16:43 -0400, Jeff Garzik wrote:
> > > ISTR Alan saying there was some ALi hardware that either wasn't in ALSA, 
> > > or most likely didn't work in ALSA.  If Alan says I'm smoking crack, 
> > > then you all can ignore me :)
> > 
> > The only big thing I know that still needed OSS (and may still do so) is
> > the support for AC97 wired touchscreens and the like. Has that been
> > ported to ALSA ?
> 
> We're working on this issue right now.

What's the current status of this issue?

> 						Jaroslav

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



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [2.6 patch] schedule obsolete OSS drivers for removal

[James Courtier-Dutton]

Olivier Galibert wrote:
> 
> As for the OSS API being crippled, I'd take the 3 ioctl calls you need
> to setup a simple stereo 16bits output with OSS than the 13 ALSA
> library calls anyday.  Especially with the impressive lack of
> documentation you get about what the hell is a period, or what you can
> do except aborting when you get an error.
> 

There is perfectly good documentation. You just have not bothered to 
look at it.
The ALSA api is good enough so you can actually decide what happens when 
you get an error. e.g. an over or under run. You can tell ALSA to stop 
the stream, or you can tell is to continue on just using silence frames 
until you send it some new sounds.
The OSS API cannot achieve that.

James

P.S. Sorry, but I had to wipe all the cross posting addresses.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Hannu Savolainen]

On Tue, 3 Jan 2006, James Courtier-Dutton wrote:

> The ALSA api is good enough so you can actually decide what happens when you
> get an error. e.g. an over or under run. You can tell ALSA to stop the stream,
> or you can tell is to continue on just using silence frames until you send it
> some new sounds.
> The OSS API cannot achieve that.
I would not say it in this way. I have intentionally left this kind of 
stuff of minimal or no importance out from the OSS API. This decision was 
made more than 10 years ago and it's still valid. In practice it 
will not take more than few hours to add this kind of interface to the 
API but I have no intention to do it. 

The cruel fact is that the application has already failed it it causes an 
overrun/underrun. There is an audible defect in the output or some 
recording data has been lost forever. There is no way to recover the 
error afterwards. So why to waste application programmer's time and 
energy with API features that can't work anyway. 

If an application has timing problems then it's better to force the 
programmer to fix the application design issues. For this reason OSS 
handles underruns in the simpliest possible way (by adding a full 
fragment of silence). This makes xruns clearly audible which in turn 
takes care that the problem will get noticed. 

With sophisticated application/driver interaction it may be possible to 
make the xrun defects almost unaudible but so what. OSS is designed for 
software professionals who do _NOT_ release applications that don't work 
correctly in the given environment. 

In OSS the application can check if an overrun/underrun has occurred and 
then make the decision to continue or abort. Most applications don't care 
about this kind of issues so all this has very limited importance.

Btw, about the subject. I would recommend quick removal of the current 
kernel OSS drivers since they are really obsolete. They are lacking all 
the development made to the OSS API during past (almost) 10 years. We are
planning to make an open source version of OSS available during this year
which will make the kernel OSS drivers unnecessary anyway.

Best regards,

Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Olivier Galibert]

On Tue, Jan 03, 2006 at 10:33:33PM +0000, James Courtier-Dutton wrote:
> Olivier Galibert wrote:
> >
> >As for the OSS API being crippled, I'd take the 3 ioctl calls you need
> >to setup a simple stereo 16bits output with OSS than the 13 ALSA
> >library calls anyday.  Especially with the impressive lack of
> >documentation you get about what the hell is a period, or what you can
> >do except aborting when you get an error.
> >
> 
> There is perfectly good documentation. You just have not bothered to 
> look at it.

Really?  Did you try finding documentation for the simple problem that
is playing dynamically generated stereo with minimum latency recently?
Because I did.  Hey, let's have fun and try it again.

Start with "alsa" is google, you find www.alsa-project.org.  Good
start.  Then you go to documentation.

Ok, let's check:

- Background info.... nah, no background info in there, only PR about
  why it's so much cooler that OSS.  Uninteresting.

- Tutorials.  Too bad they're all about 0.9, so they don't compile
  anymore.  At least they give a start, even if I'd loved to have an
  explanation of why there is writen and writei when there is
  set_access.  And they have zero information about error handling, or
  what the hell a period is (somthing like a buffer size?) or what is
  the impact of asking for multiple ones.

- Doxygen-generated reference documentation.  The API links start
  quite badly, but thankfully the PCM interface one is not empty, and it
  is not even that bad.  It is missing some relatively important things
  though, like:

  - High-level view of the application structure.

  - Some explanation of the meaning of the most non-obvious calls like
    prepare.

  - Technical glossary.  F.i. what te hell a "configuration space" is?

  - Error returns, and what to do about them.  Especially from things
    like prepare or poll_description_revents where it seems it should
    never happen.

  - Pointer on how to do simple but rather useful things, like getting
    the minimum latency possible, getting the list of devices, getting
    their capabilities (channels, hardware-supported frequencies and
    formats, modem vs. soundcard...)


> The ALSA api is good enough so you can actually decide what happens when 
> you get an error. e.g. an over or under run. You can tell ALSA to stop 
> the stream, or you can tell is to continue on just using silence frames 
> until you send it some new sounds.
> The OSS API cannot achieve that.

Talk about throwing the baby with the bathwater.

  OG.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Olivier Galibert]

On Fri, Jan 06, 2006 at 09:26:42PM +0100, Jaroslav Kysela wrote:
> You're proposing to add more content switches versus current ALSA 
> implementation:
> 
> user space <-> kernel
> 
> While your daemon requires:
> 
> user space <-> kernel <-> user space (daemon)

Dmix _is_ a context switch, you know?


> So your solution is even more realtime and proper scheduling dependant.
> Unfortunately, Linux kernels still do not have perfect realtime behaviour 
> (mostly due to broken drivers etc.).

You only get context switches if you go through plugins, which is
pretty much the same way alsa currently is, isn't it?


> Also, the API is completely irrelevant from this scheme. If daemon does 
> everything, the ALSA kernel API can go public and documented (altough I 
> still does not agree with it - see bellow).

The ALSA kernel API better go documented soon or I'll have to document
it myself.  Security and openness-wise, it is just not acceptable to
have a user-accessive kernel API kept under wraps.


> > ALSA does not have a documented kernel interface nor an optional
> > library but a mandatory library.  A highly complex, ipc-using library
> 
> It's also not very true. You can create your own ALSA library,

After reverse-engineering your kernel interface.  How convenient.


> but this library will not be supported with our team.

Of course.  You won't have to though, since you claim the API is
upwards compatible.


> The ALSA from 1.0 version is 
> binary compatible (even 0.9.0rc4+ linked applications should work) and old 
> ioctls are emulated.

Good.


> I'd like to point that this code runs with standard user priviledges. I 
> think that the security things are and should be in a different place (in 
> the kernel). If IPC is broken, other applications (not only using sound) 
> might be broken.

Every application that does inter-process communication has potential
protocol-level security issues.  Current ALSA creates two shared
memory zones and one semaphore with group write permissions.  In a
setup where a number of people are in the same group (student group
for instance), are you 100% positive that another user cannot take
control of the running application by writing the right values at the
right time in these zones?  Shared memory is the most dangerous
communication vector there is when the other application is
untrustable.


> > At least OSS, with all its flaws, is a documented kernel interface.
> > You can static link a oss-using program, whether it uses it directly
> > or through interfaces like sdl-audio, and it will just work.
> 
> Please, see your words. You're simply anarchistic. You replaced 
> flexibility of dynamic library with a possibility to have static binary.

I am indeed not really interested in reproducing the dll hell of
windows in linux.  I want simple but really efficient interfaces to
kernel services which then give the possibility to build special needs
libraries over it[1].  At that point you're designing an API for a
specific class of professional audio users and essentially telling all
the other users to bugger off.  Bad karma.


> ALSA library can be also compiled as static library, so it's not a 
> problem. The ALSA kernel API is stable.

Yeah, that's the second time you're saying that.  I'm sure Dave Jones
will be really happy to know that his impressions were mistaken and
his bugzilla was just having hallucinations:
  http://marc.theaimsgroup.com/?l=linux-kernel&m=113589615627420&w=2
  http://marc.theaimsgroup.com/?l=linux-kernel&m=113225994603627&w=2


> Also, we use symbol versions for 
> all exported functions, so all old binaries linked with the dynamic alsa 
> library will work.

Like all the programs I had which segfaulted after the alsa upgrade
that changed set_rate_near.  Beautiful versioning there guys.


> Of course, the drivers might change some universal 
> control names,

Yeah, also known as "the stick which broke jwz's back".


> Also note, that if OSS had the API in userspace from the first days,
> the emulation or redirection of this API to another API or user space 
> drivers wouldn't be so much complicated nowadays. Bummer.

It would be exactly as complicated because of the static link issue.

  OG.

[1] SDL, jack and slmodem are I think good examples


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

On Sat, 7 Jan 2006, Takashi Iwai wrote:

> > > Because OSS API doesn't cover many things.  For example, 
> > > 
> > > - PCM with non-interleaved formats
> > There is no need to handle non-interleaved data in kernel level drivers 
> > because all the devices use interleaved formats.
> 
> Many RME boards support only non-intereleave data.
In such cases it's better to do interleavin/deinterleaving in the kernel 
rather than forcing the apps to check which method they should use.

Using non-interleaved instead of interleaved as the format was an 
alternative that I considered very early. Non-interleaved is easier to 
understand for the programmers. However all devices (with exceptions 
you mentioned) use interleaved and in the early days (386/486) 
re-interleaving appeared to be too time consuming.

> > > - PCM with 3-bytes-packed 24bit formats
> > Applications have no reasons to use for this kind of stupid format so OSS 
> > translates it to the usual 32 bit format on fly. In fact OSS API does 
> > have support for this format.
> 
> Well, this is stupid but very popular nowadays, unforunately :)
In user land? (I see you are just joking). I know USB devices use this 
inpractical format due to USB bus bandwidth limitations. However I'm 100% 
sure no programmer feels happy with it.
 
> > > - Combination of multiple devices
> > > - Split of channels to concurrent accesses
> > Could you be more specific with the above isues?
> 
> I meant to split channels of a single device to different processes
> (e.g. front/rear/clfe for each).  (I know it's doable but the question
> is how to implement it.)
By having a device file for each channel (or stereo pair) with their 
private kernel buffers. The output interrupt handler then picks the 
samples from each buffer and interleaves them to the output. Right, this 
can be done in user land too but is it really easier in that way?
 
> > > Forcing OSS API means to force to process the all things above in
> > > the kernel.  I guess many people would disagree with it.
> > Wrong. This is not an API issue at all. It's an implementation one. 
> 
> Indeed.  But you know that almost all "OSS" applications access
> directly the device files.  There is no room to put a library to solve
> these things in user-space.
Why should there be any need to put library code between the kernel API 
and an application that is perfectly happy with it? It is only necessary 
if somebody wants to emulate the OSS kernel API in library level.

A wrapper library with routines like oss_open, oss_write, etc was once 
considered. However we didn't find any good reason to do that (in 
particular because that conflicted with routine names already used 
internally in some important OSS applications).
 

> 
> > An alternative for doing some operations in the kernel is looping the 
> > audio data through an user land daemon. The application itself is still 
> > using the usual OSS API without knowing anything about any daemons. We 
> > have tested this approach and it works. There just has not been any good 
> > reason to use this approach instead of using kernel space approach. 
> > Passing data through multiple applications makes the latency issues to 
> > accumulate. If you do the processing in the kernel you will hit by the 
> > task scheduling latencies at most once.
> 
> Yes, I thought of the similar thing...  But, is it really a preferred
> approach?
We found out that doing the things we wanted to do was actually much 
easier in kernel space. 

The perfect solution requires possibility to run privileged semi-userland 
tasks between the kernel and the device switch table. If such task can 
access limited set of kernel services (sleep/wake, mutexes, timers and few 
others) while still being able to do FP and access normal user land 
services then...
However I think this is just a day dream because more or less major 
changes would be required to the kernel. In addition using just two 
protection rings is one of the key foundations of the Linux kernel.

> 
> > The OSS approach is not to make everything in the kernel. Things that can 
> > be done easier in the applications (or in libraries) have been left 
> > out from the API.
> 
> Basically, it's not 100% fault of OSS, IMO.  But, looking at the
> reality, apps do access directly to the kernel.  It's worse in the
> case of binary-only apps like flash or skype.  To support these
> things, the only "realistic" (OSS-ish) solution so far is to implement
> the conversion routines in the kernel level.
What if there is some better way to handle OSS-ALSA interaction than 
library level hooks/emulation. In the short term this may be difficult 
because OSS is binary only and outside the kernel. But in long run OSS can 
hopefully be open sourced which could make it possible to use solutions 
like merging the kernel space drivers together.

Actually I have forgotten what was the reason why you wanted to get the 
OSS API emulated in userland rather than using the previous snd-oss 
module (which worked well other than the API version you emulated was too 
old)?

Best regards,

Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [OT] ALSA userspace API complexity

[Olivier Galibert]

On Sat, Jan 07, 2006 at 03:32:27PM +0100, Takashi Iwai wrote:
> Yes, it's a known problem to be fixed.  But, it's no excuse to do
> _everything_ in the kernel (which OSS requires).

OSS does not require to do anything in the kernel except an entry
point.


> And if the application doesn't support, who and where converts it?
> With OSS API, it's a job of the kernel.

Once again no.  Nothing prevents the kernel to forward the data to
userland daemons depending on a userspace-uploaded configuration.

  OG.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [OT] ALSA userspace API complexity

[Martin Drab]

On Sun, 8 Jan 2006, Olivier Galibert wrote:

> > And if the application doesn't support, who and where converts it?
> > With OSS API, it's a job of the kernel.
> 
> Once again no.  Nothing prevents the kernel to forward the data to
> userland daemons depending on a userspace-uploaded configuration.

I think that the point was, that switching from userspace to kernelspace 
then to userspace again and back to kernelspace in order to do something, 
that could have been done directly in the userspace, and though could save 
those two unnecessary switches, is an unnecessary overhead, which may not 
necessarily be that insignificant if it's done so often (which for 
streaming audio is the case). Why doing things complicated when there is 
no evident gain from it, or is there?

Martin


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

On Sun, 8 Jan 2006, Hannu Savolainen wrote:

> On Sat, 7 Jan 2006, Takashi Iwai wrote:
> 
> > > > Because OSS API doesn't cover many things.  For example, 
> > > > 
> > > > - PCM with non-interleaved formats
> > > There is no need to handle non-interleaved data in kernel level drivers 
> > > because all the devices use interleaved formats.
> > 
> > Many RME boards support only non-intereleave data.
> In such cases it's better to do interleavin/deinterleaving in the kernel 
> rather than forcing the apps to check which method they should use.

I don't think so. The library can do such conversions (and alsa-lib does) 
quite easy. If we have a possibility to remove the code from the kernel 
space without any drawbacks, then it should be removed. I don't see any 
advantage to have such conversions in the kernel.

> > Indeed.  But you know that almost all "OSS" applications access
> > directly the device files.  There is no room to put a library to solve
> > these things in user-space.
> Why should there be any need to put library code between the kernel API 
> and an application that is perfectly happy with it? It is only necessary 
> if somebody wants to emulate the OSS kernel API in library level.
> 
> A wrapper library with routines like oss_open, oss_write, etc was once 
> considered. However we didn't find any good reason to do that (in 
> particular because that conflicted with routine names already used 
> internally in some important OSS applications).

Bad decision. Again, I feel you're hidding the flexibility against
your feeling that the kernel API is the best enough for applications.
Imagine that the API redirection is or can be also flexible for your 
future development.

> What if there is some better way to handle OSS-ALSA interaction than 
> library level hooks/emulation. In the short term this may be difficult 
> because OSS is binary only and outside the kernel. But in long run OSS can 
> hopefully be open sourced which could make it possible to use solutions 
> like merging the kernel space drivers together.
> 
> Actually I have forgotten what was the reason why you wanted to get the 
> OSS API emulated in userland rather than using the previous snd-oss 
> module (which worked well other than the API version you emulated was too 
> old)?

Stream mixing. We have user space solution while you insist to put this 
code to kernel. Simply, we need to go through our library.

>From the end user perspective, don't you think that having an opportunity 
to change the API entry point from one to multiple (user space library - 
preferred, direct kernel space - last resort) is more flexible for 
developers and users? Please, consider this question without any flames 
line which API is better and what's better for audio subsystem architects 
and what's better for your commercial work.

						Jaroslav

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


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

On Sun, 8 Jan 2006, Olivier Galibert wrote:

> On Sat, Jan 07, 2006 at 03:32:27PM +0100, Takashi Iwai wrote:
> > Yes, it's a known problem to be fixed.  But, it's no excuse to do
> > _everything_ in the kernel (which OSS requires).
> 
> OSS does not require to do anything in the kernel except an entry
> point.
> 
> 
> > And if the application doesn't support, who and where converts it?
> > With OSS API, it's a job of the kernel.
> 
> Once again no.  Nothing prevents the kernel to forward the data to
> userland daemons depending on a userspace-uploaded configuration.

But it's quite ineffecient. The kernel must switch tasks at least twice
or more. It's the major problem with the current OSS API.

						Jaroslav

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


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [OT] ALSA userspace API complexity

[Olivier Galibert]

On Sun, Jan 08, 2006 at 10:42:02AM +0100, Jaroslav Kysela wrote:
> On Sun, 8 Jan 2006, Olivier Galibert wrote:
> 
> > On Sat, Jan 07, 2006 at 03:32:27PM +0100, Takashi Iwai wrote:
> > > Yes, it's a known problem to be fixed.  But, it's no excuse to do
> > > _everything_ in the kernel (which OSS requires).
> > 
> > OSS does not require to do anything in the kernel except an entry
> > point.
> > 
> > 
> > > And if the application doesn't support, who and where converts it?
> > > With OSS API, it's a job of the kernel.
> > 
> > Once again no.  Nothing prevents the kernel to forward the data to
> > userland daemons depending on a userspace-uploaded configuration.
> 
> But it's quite ineffecient. The kernel must switch tasks at least twice
> or more. It's the major problem with the current OSS API.

Once.  U->K or K->U is not task switching and accordingly has a very
low cost.  It's changing of userspace task that is costly.  And dmix
_is_ a task switch, there is no performance difference between talking
with it through shared memory and semaphores and who knows what else
and talking with it through a kernel interface.

You should count how many U-U switches and U-K syscalls communicating
with dmix represents.  Hard to do for a simple user, since the
protocol is not documented.

  OG.



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [OT] ALSA userspace API complexity

[Olivier Galibert]

On Sun, Jan 08, 2006 at 03:26:18AM +0100, Martin Drab wrote:
> On Sun, 8 Jan 2006, Olivier Galibert wrote:
> 
> > > And if the application doesn't support, who and where converts it?
> > > With OSS API, it's a job of the kernel.
> > 
> > Once again no.  Nothing prevents the kernel to forward the data to
> > userland daemons depending on a userspace-uploaded configuration.
> 
> I think that the point was, that switching from userspace to kernelspace 
> then to userspace again and back to kernelspace in order to do something, 
> that could have been done directly in the userspace, and though could save 
> those two unnecessary switches, is an unnecessary overhead, which may not 
> necessarily be that insignificant if it's done so often (which for 
> streaming audio is the case).

You all seem to forget that dmix is in userspace in a different task
too.


> Why doing things complicated when there is no evident gain from it,
> or is there?

No evident gain?  Wow.  What about:
- stopping crippling the OSS api

- having a real kernel api for which you can make different libraries
  depending on the need of the users

- stop making a fundamentally unsecure shared library mandatory

- opening the possibility of writing plugins to people without a PhD
  in lattice QCD.

and that's just a start.

  OG.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

On Sun, 8 Jan 2006, Olivier Galibert wrote:

> On Sun, Jan 08, 2006 at 10:42:02AM +0100, Jaroslav Kysela wrote:
> > On Sun, 8 Jan 2006, Olivier Galibert wrote:
> > 
> > > On Sat, Jan 07, 2006 at 03:32:27PM +0100, Takashi Iwai wrote:
> > > > Yes, it's a known problem to be fixed.  But, it's no excuse to do
> > > > _everything_ in the kernel (which OSS requires).
> > > 
> > > OSS does not require to do anything in the kernel except an entry
> > > point.
> > > 
> > > 
> > > > And if the application doesn't support, who and where converts it?
> > > > With OSS API, it's a job of the kernel.
> > > 
> > > Once again no.  Nothing prevents the kernel to forward the data to
> > > userland daemons depending on a userspace-uploaded configuration.
> > 
> > But it's quite ineffecient. The kernel must switch tasks at least twice
> > or more. It's the major problem with the current OSS API.
> 
> Once.  U->K or K->U is not task switching and accordingly has a very
> low cost.  It's changing of userspace task that is costly.  And dmix
> _is_ a task switch, there is no performance difference between talking
> with it through shared memory and semaphores and who knows what else
> and talking with it through a kernel interface.
> 
> You should count how many U-U switches and U-K syscalls communicating
> with dmix represents.  Hard to do for a simple user, since the
> protocol is not documented.

You're in a mistake. For x86, there are no U-K syscalls for dmix and no 
extra U-U task switches, even the latency is same as for the direct 
hardware access, because we're using a lockless technique. Also, in case 
of use of using mutexes for other architectures, there is only task switch 
when mutex is locked when the real mixing is in progress (the mixing is 
really small time windows, so it's rare to have mutex locked).

In case of a mixing daemon, you need to regulary woke up a task in a time 
period (probably with a highter time interval than application are feeding 
new samples). So you have at least one U-U task switch in the perfect 
conditions (all sound applications delivered data "in time").

						Jaroslav

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


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

On Sun, 8 Jan 2006, Olivier Galibert wrote:

> On Sun, Jan 08, 2006 at 03:26:18AM +0100, Martin Drab wrote:
> > On Sun, 8 Jan 2006, Olivier Galibert wrote:
> > 
> > > > And if the application doesn't support, who and where converts it?
> > > > With OSS API, it's a job of the kernel.
> > > 
> > > Once again no.  Nothing prevents the kernel to forward the data to
> > > userland daemons depending on a userspace-uploaded configuration.
> > 
> > I think that the point was, that switching from userspace to kernelspace 
> > then to userspace again and back to kernelspace in order to do something, 
> > that could have been done directly in the userspace, and though could save 
> > those two unnecessary switches, is an unnecessary overhead, which may not 
> > necessarily be that insignificant if it's done so often (which for 
> > streaming audio is the case).
> 
> You all seem to forget that dmix is in userspace in a different task
> too.

Because it is really not. The mixing is done directly to the mmaped DMA 
buffer.

> > Why doing things complicated when there is no evident gain from it,
> > or is there?
> 
> No evident gain?  Wow.  What about:
> - stopping crippling the OSS api

We're not doing that. We're just showing that OSS API and useability has 
it's own problems, too.

> - having a real kernel api for which you can make different libraries
>   depending on the need of the users
> 
> - stop making a fundamentally unsecure shared library mandatory

ALSA kernel API is real and binary compatible. If someone require to
write an own library, we will document this API, of course, too.

> - opening the possibility of writing plugins to people without a PhD
>   in lattice QCD.

Already done. We have official plugin SDK in alsa-lib to create user space 
drivers. If you have some questions or bug-reports (missing docs etc), 
please, fill a bug report.

Also, you can use very simple LADSPA plugin style, because alsa-lib can 
use LADSPA plugins directly, too.

						Jaroslav

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


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [OT] ALSA userspace API complexity

[Marcin Dalecki]

On 2006-01-08, at 10:42, Jaroslav Kysela wrote:
>>
>> Once again no.  Nothing prevents the kernel to forward the data to
>> userland daemons depending on a userspace-uploaded configuration.
>
> But it's quite ineffecient. The kernel must switch tasks at least  
> twice
> or more. It's the major problem with the current OSS API.

1. It was only presented as an opportunity. Not every data has to go  
this way.
2. Aren't you the person which was showing off X11 as a good example  
to draw guidelines from?


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

On Sun, 8 Jan 2006, Jaroslav Kysela wrote:

> I don't think so. The library can do such conversions (and alsa-lib does) 
> quite easy. If we have a possibility to remove the code from the kernel 
> space without any drawbacks, then it should be removed. I don't see any 
> advantage to have such conversions in the kernel.
The advantage is that you don't need any libraries. 
 
> Bad decision. Again, I feel you're hidding the flexibility against
> your feeling that the kernel API is the best enough for applications.
> Imagine that the API redirection is or can be also flexible for your 
> future development.
Past 13 years have proven that kernel only API has been very successfull.
There are 1000's of applications supporting it and being a kernel 
only API has not caused any problems. If something cannot be implemented 
in kernel (like effect plugins) then a library can be implemented on top 
of the OSS kernel API which has already been done by other developers.
 
Right. Emulating OSS API in userland is difficult in this way. I just 
couldn't imagine that somebody wants to do that. It can be considered as 
my fault.

> > Actually I have forgotten what was the reason why you wanted to get the 
> > OSS API emulated in userland rather than using the previous snd-oss 
> > module (which worked well other than the API version you emulated was too 
> > old)?
> 
> Stream mixing. We have user space solution while you insist to put this 
> code to kernel. Simply, we need to go through our library.
I wonder if foing mixing (summing) of streams in kernel really causes more 
problems than emulating a kernel API in user space.

> >From the end user perspective, don't you think that having an opportunity 
> to change the API entry point from one to multiple (user space library - 
> preferred, direct kernel space - last resort) is more flexible for 
> developers and users? Please, consider this question without any flames 
> line which API is better and what's better for audio subsystem architects 
> and what's better for your commercial work.
It's too late to discuss about this. This decision could have been made in 
1992-1993 before large number of applications were already written. 
Unfortunately the whole issue was raised just recently.

There has been definitions for routines like osslib_open(), etc in 
soundcard.h for years. Also the libOSSlib.so library contains such 
routines. If an OSS application is compiled without -DOSSLIB then they are 
defined as open, etc. Unfortunately this version of soundcard.h was not 
accepted by the kernel OSS maintainers so the stock Linux version doesn't 
have these definitions.

If you like to get OSS apps to go through this library API you can do the 
following:

- Get the latest soundcard.h from our OSS package to be included in the 
stock kernel.
- Do the same for libOSSlib (sources shipped with OSS).
- Tell all OSS developers to change all OSS system calls to use their 
osslib_ counterparts. And to recompile against the latest soundcard.h
with -DOSSLIB. Make sure all distributions have done the changes before 
that.

Then you can include a libOSSlib.o library in ALSA with all the OSS 
emulation stuf inside.

Best regards,

Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [OT] ALSA userspace API complexity

[Pavel Machek]

On Ne 08-01-06 14:32:40, Jaroslav Kysela wrote:
> ALSA kernel API is real and binary compatible. If someone require to
> write an own library, we will document this API, of course, too.

The documentation would be nice, regardless of other libraries. It is
kernel API and that really should be documented.
								Pavel

-- 
Thanks, Sharp!


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

On Sun, 8 Jan 2006, Jaroslav Kysela wrote:

> On Sun, 8 Jan 2006, Olivier Galibert wrote:
> 
> > Once again no.  Nothing prevents the kernel to forward the data to
> > userland daemons depending on a userspace-uploaded configuration.
> 
> But it's quite ineffecient. The kernel must switch tasks at least twice
> or more. 
Actually there is just one extra context switch. When the application 
using the API interface has finished it's current buffer it goes to sleep 
(sooner or later). With no OSS kernel task then the context is 
switched to the next process in the ready list. With the OSS task there is 
one extra context switch to the task before the inevitable switch to 
some other task in the system.

In CPU usage perspective this is nothing significant. This kind of 
approach makes only sense if the extra task is going to do some 
significant processing. So even if there is one context switch (and 
possibly some data copying) related with this mechanism the load caused to 
it is microscopic when compared to the actual processing. There is no real 
difference when compared to a pure library solution.

What is problem is that context switching delays make it necessary to use 
slightly larger buffers. This causes increased latencies which may or may 
not cause problems with some timing critical applications. OTOH with OSS 
API the application can disable this kind of extra stuff if it needs 
"traditional" access directly to the device.

> It's the major problem with the current OSS API.
I don't see there any problem. In particular it's in no way an API 
issue. Everything that has been found to be necessary for applications is 
included in OSS API and all it has been implemented in kernel space. 

Best regards,

Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

On Sun, 8 Jan 2006, Jaroslav Kysela wrote:

> > - having a real kernel api for which you can make different libraries
> >   depending on the need of the users
> > 
> > - stop making a fundamentally unsecure shared library mandatory
> 
> ALSA kernel API is real and binary compatible. 
Less than an year ago you (or was it Takashi) told that the kernel API 
cannot be used or documented because it may be changed any time without 
notice.

Best regards,

Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[Takashi Iwai]

At Mon, 9 Jan 2006 02:33:43 +0200 (EET),
Hannu Savolainen wrote:
> 
> On Sun, 8 Jan 2006, Jaroslav Kysela wrote:
> 
> > > - having a real kernel api for which you can make different libraries
> > >   depending on the need of the users
> > > 
> > > - stop making a fundamentally unsecure shared library mandatory
> > 
> > ALSA kernel API is real and binary compatible. 
> Less than an year ago you (or was it Takashi) told that the kernel API 
> cannot be used or documented because it may be changed any time without 
> notice.

Hmm, that might be me.  I meant as a merit of a common library as the
API entry.  Of course, the kernel API will be kept as much as possible
as we have done it so.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[René Rebe]

Hi,

On Sunday 08 January 2006 10:24, Jaroslav Kysela wrote:

> > > > > - PCM with non-interleaved formats
> > > > There is no need to handle non-interleaved data in kernel level drivers 
> > > > because all the devices use interleaved formats.
> > > 
> > > Many RME boards support only non-intereleave data.
> > In such cases it's better to do interleavin/deinterleaving in the kernel 
> > rather than forcing the apps to check which method they should use.
> 
> I don't think so. The library can do such conversions (and alsa-lib does) 
> quite easy. If we have a possibility to remove the code from the kernel 
> space without any drawbacks, then it should be removed. I don't see any 
> advantage to have such conversions in the kernel.

Also, when the data is already available as single streams in a user-space
multi track application, why should it be forced interleaved, when the hardware
could handle the format just fine?

Yours,
  Rene

-- 
ExactCODE, Berlin


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2015 bytes --]

On Mon, 9 Jan 2006, René Rebe wrote:

> > I don't think so. The library can do such conversions (and alsa-lib does) 
> > quite easy. If we have a possibility to remove the code from the kernel 
> > space without any drawbacks, then it should be removed. I don't see any 
> > advantage to have such conversions in the kernel.
> 
> Also, when the data is already available as single streams in a user-space
> multi track application, why should it be forced interleaved, when the hardware
> could handle the format just fine?
Because the conversion doesn't cost anything. Trying to avoid it by 
making the API more complicated (I would even say confusing) is extreme 
overkill. 

Each feature of this kind requires two additional API 
calls (one for checking in which way the hardware works and another to 
set the device to use the feature). It's also possible to implement the 
feature in a way that requires more new calls. By adding support for 
dozens of features like this it's easy to create an API that has 1500+ 
calls.

Even worse this kind of features weaken the device abstraction provided by 
the API. The applications will have to check for this and 
that and provide support for 100s of special cases that may be required by 
certain devices. 

IMHO this has already happened with ALSA. Normal 
programmers (other than few of the world class gurus) have no way to 
understand the API. I would consider myself at least moderately 
experienced sound programmer (25+ years of programming experience and more 
than half of it on sound). However even after two years of more or less 
intense learning I don't know what is the preferred way to use ALSA. I 
think this is a general problem because practically all ALSA applications use 
different ALSA API calls.

Best regards,

Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM

Re: Re: [OT] ALSA userspace API complexity

[René Rebe]

Hi,

On Monday 09 January 2006 16:10, Hannu Savolainen wrote:

> > > I don't think so. The library can do such conversions (and alsa-lib does) 
> > > quite easy. If we have a possibility to remove the code from the kernel 
> > > space without any drawbacks, then it should be removed. I don't see any 
> > > advantage to have such conversions in the kernel.
> > 
> > Also, when the data is already available as single streams in a user-space
> > multi track application, why should it be forced interleaved, when the hardware
> > could handle the format just fine?
> Because the conversion doesn't cost anything. Trying to avoid it by 
> making the API more complicated (I would even say confusing) is extreme 
> overkill. 

Since when doesn't cost convesion anything? I'm able to count a lot of wasted
CPU cycles in there ...

> Even worse this kind of features weaken the device abstraction provided by 
> the API. The applications will have to check for this and 
> that and provide support for 100s of special cases that may be required by 
> certain devices. 

An lame write() only player can still open the default device and get the auto-convert
chain it deserves ...

Yours,
  Rene Rebe

-- 
ExactCODE Berlin


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[Thierry Vignaud]

Olivier Galibert <galibert@pobox.com> writes:

> - stop making a fundamentally unsecure shared library mandatory

do you speak about known vulnerabilities in ALSA lib or are you
trolling^h^h^h^h^h^h^h assuming that kernel code is safer than
userspace one?

afaic I don't assume this.
I'd prefer see bad code make one app crashing than oopsing the whole
machine.



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[David Lang]

On Mon, 9 Jan 2006, René Rebe wrote:

> On Monday 09 January 2006 16:10, Hannu Savolainen wrote:
>
>>>> I don't think so. The library can do such conversions (and alsa-lib does)
>>>> quite easy. If we have a possibility to remove the code from the kernel
>>>> space without any drawbacks, then it should be removed. I don't see any
>>>> advantage to have such conversions in the kernel.
>>>
>>> Also, when the data is already available as single streams in a user-space
>>> multi track application, why should it be forced interleaved, when the hardware
>>> could handle the format just fine?
>> Because the conversion doesn't cost anything. Trying to avoid it by
>> making the API more complicated (I would even say confusing) is extreme
>> overkill.
>
> Since when doesn't cost convesion anything? I'm able to count a lot of wasted
> CPU cycles in there ...

if the data needed to be accessed by the CPU anyway it's free becouse 
otherwise the CPU would stall waiting for the next chunk of memory. you 
can do quite a bit of work on data in cache while you are waiting for the 
next cache line to load.

in this same way, checksumming a network packet is free if the CPU needs 
to copy the data anway, it only costs something if the data could bypass 
the CPU.

David Lang

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[John Rigg]

On Mon, Jan 09, 2006 at 01:58:00PM -0800, David Lang wrote:
> On Mon, 9 Jan 2006, René Rebe wrote:
> 
> >On Monday 09 January 2006 16:10, Hannu Savolainen wrote:
> >
> >>>>I don't think so. The library can do such conversions (and alsa-lib 
> >>>>does)
> >>>>quite easy. If we have a possibility to remove the code from the kernel
> >>>>space without any drawbacks, then it should be removed. I don't see any
> >>>>advantage to have such conversions in the kernel.
> >>>
> >>>Also, when the data is already available as single streams in a 
> >>>user-space
> >>>multi track application, why should it be forced interleaved, when the 
> >>>hardware
> >>>could handle the format just fine?
> >>Because the conversion doesn't cost anything. Trying to avoid it by
> >>making the API more complicated (I would even say confusing) is extreme
> >>overkill.
> >
> >Since when doesn't cost convesion anything? I'm able to count a lot of 
> >wasted
> >CPU cycles in there ...
> 
> if the data needed to be accessed by the CPU anyway it's free becouse 
> otherwise the CPU would stall waiting for the next chunk of memory. you 
> can do quite a bit of work on data in cache while you are waiting for the 
> next cache line to load.
> 
> in this same way, checksumming a network packet is free if the CPU needs 
> to copy the data anway, it only costs something if the data could bypass 
> the CPU.

Yes, but the CPU has plenty of other work to do. The sound cards that
would be worst affected by this are the big RME cards (non-interleaved) and
multiple ice1712 cards (non-interleaved blocks of interleaved data),
which AFAIK are the only cards capable of handling serious professional audio.
This could represent 48 or more channels of 96kHz audio, which
doesn't leave a lot of spare CPU capacity for running X, for example.

John


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[David Lang]

On Mon, 9 Jan 2006, John Rigg wrote:

> On Mon, Jan 09, 2006 at 01:58:00PM -0800, David Lang wrote:
>> On Mon, 9 Jan 2006, René Rebe wrote:
>>>>>
>>>>> Also, when the data is already available as single streams in a
>>>>> user-space
>>>>> multi track application, why should it be forced interleaved, when the
>>>>> hardware
>>>>> could handle the format just fine?
>>>> Because the conversion doesn't cost anything. Trying to avoid it by
>>>> making the API more complicated (I would even say confusing) is extreme
>>>> overkill.
>>>
>>> Since when doesn't cost convesion anything? I'm able to count a lot of
>>> wasted
>>> CPU cycles in there ...
>>
>> if the data needed to be accessed by the CPU anyway it's free becouse
>> otherwise the CPU would stall waiting for the next chunk of memory. you
>> can do quite a bit of work on data in cache while you are waiting for the
>> next cache line to load.
>>
>> in this same way, checksumming a network packet is free if the CPU needs
>> to copy the data anway, it only costs something if the data could bypass
>> the CPU.
>
> Yes, but the CPU has plenty of other work to do. The sound cards that
> would be worst affected by this are the big RME cards (non-interleaved) and
> multiple ice1712 cards (non-interleaved blocks of interleaved data),
> which AFAIK are the only cards capable of handling serious professional audio.
> This could represent 48 or more channels of 96kHz audio, which
> doesn't leave a lot of spare CPU capacity for running X, for example.

does the CPU touch the data for these, or do you DMA directly from 
userspace (i.e. "zero-copy")?

if the cpu touches this data on it's way in and out of the system then you 
are going to have a time period where you are maxing out the memory bus of 
your CPU (this may be a short time, but since the bus is either active or 
not there will be a time when it's active transfering audio data :-). 
while the memory bus is busy transfering the audio data your cpu can only 
work on data that's in the cache.

remember that as you keep reading the data from memory it will push other 
stuff out of your cache.

what magic do you pull to have the CPU busy on other things while the 
cache (and memory bus) is being occupied by the audio data transfers?

David Lang

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[John Rigg]

On Mon, Jan 09, 2006 at 03:21:21PM -0800, David Lang wrote:
> On Mon, 9 Jan 2006, John Rigg wrote:
> 
> >On Mon, Jan 09, 2006 at 01:58:00PM -0800, David Lang wrote:
> >>On Mon, 9 Jan 2006, René Rebe wrote:
> >>>>>
> >>>>>Also, when the data is already available as single streams in a
> >>>>>user-space
> >>>>>multi track application, why should it be forced interleaved, when the
> >>>>>hardware
> >>>>>could handle the format just fine?
> >>>>Because the conversion doesn't cost anything. Trying to avoid it by
> >>>>making the API more complicated (I would even say confusing) is extreme
> >>>>overkill.
> >>>
> >>>Since when doesn't cost convesion anything? I'm able to count a lot of
> >>>wasted
> >>>CPU cycles in there ...
> >>
> >>if the data needed to be accessed by the CPU anyway it's free becouse
> >>otherwise the CPU would stall waiting for the next chunk of memory. you
> >>can do quite a bit of work on data in cache while you are waiting for the
> >>next cache line to load.
> >>
> >>in this same way, checksumming a network packet is free if the CPU needs
> >>to copy the data anway, it only costs something if the data could bypass
> >>the CPU.
> >
> >Yes, but the CPU has plenty of other work to do. The sound cards that
> >would be worst affected by this are the big RME cards (non-interleaved) and
> >multiple ice1712 cards (non-interleaved blocks of interleaved data),
> >which AFAIK are the only cards capable of handling serious professional 
> >audio.
> >This could represent 48 or more channels of 96kHz audio, which
> >doesn't leave a lot of spare CPU capacity for running X, for example.
> 
> does the CPU touch the data for these, or do you DMA directly from 
> userspace (i.e. "zero-copy")?

The cards I mentioned use DMA. RME actually advertises that some of their
cards can handle 52 channels with zero CPU load. Their onboard DSPs can
also do routing and mixing, again without touching the CPU.

John


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[David Lang]

On Tue, 10 Jan 2006, John Rigg wrote:

>> does the CPU touch the data for these, or do you DMA directly from
>> userspace (i.e. "zero-copy")?
>
> The cards I mentioned use DMA. RME actually advertises that some of their
> cards can handle 52 channels with zero CPU load. Their onboard DSPs can
> also do routing and mixing, again without touching the CPU.

I was under the (apparently mistaken) impression that you couldn't DMA 
from userspace (something to do with the possibility that the userspace 
memory pages could be swapped out in the middle of the DMA)

David Lang

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[Alan Cox]

On Llu, 2006-01-09 at 16:29 -0800, David Lang wrote:
> I was under the (apparently mistaken) impression that you couldn't DMA 
> from userspace (something to do with the possibility that the userspace 
> memory pages could be swapped out in the middle of the DMA)

Drivers can choose to support this two different ways. One is to have a
buffer of kernel memory mapped into user space and shared with the
hardware (this is how OSS did it), the other is to use the 2.6
get_user_pages API to get the physical address of a set of pages and
lock them down so they don't wander off during DMA.

Both have advantages for different uses.

Alan



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

On Mon, 9 Jan 2006, John Rigg wrote:

> Yes, but the CPU has plenty of other work to do. The sound cards that
> would be worst affected by this are the big RME cards (non-interleaved) and
> multiple ice1712 cards (non-interleaved blocks of interleaved data),
ice1712 uses normal interleaving. There are no "non-interleaved blocks".

> which AFAIK are the only cards capable of handling serious professional audio.
> This could represent 48 or more channels of 96kHz audio, which
> doesn't leave a lot of spare CPU capacity for running X, for example.

This is true only if you run the system at full 100% load before the 
conversions. But in real life you cannot do this anyway. You have to use 
a CPU that has lot of spare power. Otherwise anything unpredictable will 
make things to fail.

Best regards,

Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[John Rigg]

On Tue, Jan 10, 2006 at 12:16:17AM +0000, John Rigg wrote:
> On Mon, Jan 09, 2006 at 03:21:21PM -0800, David Lang wrote:
> > does the CPU touch the data for these, or do you DMA directly from 
> > userspace (i.e. "zero-copy")?
> 
> The cards I mentioned use DMA. RME actually advertises that some of their
> cards can handle 52 channels with zero CPU load. Their onboard DSPs can
> also do routing and mixing, again without touching the CPU.

Of course I should also mention that the sound cards deal with PCM audio
samples in integer format, but audio apps like jackd and its clients use
floating point, so in practice the CPU is still processing audio data much
of the time.

John


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[John Rigg]

On Mon, Jan 09, 2006 at 04:29:45PM -0800, David Lang wrote:
> On Tue, 10 Jan 2006, John Rigg wrote:
> 
> >>does the CPU touch the data for these, or do you DMA directly from
> >>userspace (i.e. "zero-copy")?
> >
> >The cards I mentioned use DMA. RME actually advertises that some of their
> >cards can handle 52 channels with zero CPU load. Their onboard DSPs can
> >also do routing and mixing, again without touching the CPU.
> 
> I was under the (apparently mistaken) impression that you couldn't DMA 
> from userspace (something to do with the possibility that the userspace 
> memory pages could be swapped out in the middle of the DMA)

Hmm. Maybe I've been paying too much attention to card vendors'
sales talk :)

John


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[Lee Revell]

On Tue, 2006-01-10 at 00:44 +0000, Alan Cox wrote:
> On Llu, 2006-01-09 at 16:29 -0800, David Lang wrote:
> > I was under the (apparently mistaken) impression that you couldn't DMA 
> > from userspace (something to do with the possibility that the userspace 
> > memory pages could be swapped out in the middle of the DMA)
> 
> Drivers can choose to support this two different ways. One is to have a
> buffer of kernel memory mapped into user space and shared with the
> hardware (this is how OSS did it), the other is to use the 2.6
> get_user_pages API to get the physical address of a set of pages and
> lock them down so they don't wander off during DMA.
> 
> Both have advantages for different uses.

ALSA would appear to use the first method (get_user_pages does not
appear in the source), presumably because new ALSA versions still
support 2.4 (and 2.2, maybe even 2.0).

Lee



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[John Rigg]

On Tue, Jan 10, 2006 at 02:48:35AM +0200, Hannu Savolainen wrote:
> On Mon, 9 Jan 2006, John Rigg wrote:
> 
> > Yes, but the CPU has plenty of other work to do. The sound cards that
> > would be worst affected by this are the big RME cards (non-interleaved) and
> > multiple ice1712 cards (non-interleaved blocks of interleaved data),
> ice1712 uses normal interleaving. There are no "non-interleaved blocks".

With two ice1712 cards I had to patch jackd for MMAP_COMPLEX
support to make them work together. My understanding was that the
individual cards use interleaved data, but when several are combined
the resulting blocks of data are not interleaved together. I realise the
usual way of dealing with this is to use the alsa route plugin with
ttable to interleave them, but I couldn't get it to work with these
cards.

John


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

On Tue, 10 Jan 2006, John Rigg wrote:

> On Tue, Jan 10, 2006 at 02:48:35AM +0200, Hannu Savolainen wrote:
> > On Mon, 9 Jan 2006, John Rigg wrote:
> > 
> > > Yes, but the CPU has plenty of other work to do. The sound cards that
> > > would be worst affected by this are the big RME cards (non-interleaved) and
> > > multiple ice1712 cards (non-interleaved blocks of interleaved data),
> > ice1712 uses normal interleaving. There are no "non-interleaved blocks".
> 
> With two ice1712 cards I had to patch jackd for MMAP_COMPLEX
> support to make them work together. My understanding was that the
> individual cards use interleaved data, but when several are combined
> the resulting blocks of data are not interleaved together. I realise the
> usual way of dealing with this is to use the alsa route plugin with
> ttable to interleave them, but I couldn't get it to work with these
> cards.
Right. If you use two cards then both of them have independently 
interleaved blocks. However if this kind of mapping belongs to the lowest 
level audio API or not is yet another API feature to argue about.  Higher 
level libraries like Jack could do this themselves.

Best regards,

Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

On Mon, 9 Jan 2006, Hannu Savolainen wrote:

> > >From the end user perspective, don't you think that having an opportunity 
> > to change the API entry point from one to multiple (user space library - 
> > preferred, direct kernel space - last resort) is more flexible for 
> > developers and users? Please, consider this question without any flames 
> > line which API is better and what's better for audio subsystem architects 
> > and what's better for your commercial work.
> It's too late to discuss about this. This decision could have been made in 
> 1992-1993 before large number of applications were already written. 
> Unfortunately the whole issue was raised just recently.
> 
> There has been definitions for routines like osslib_open(), etc in 
> soundcard.h for years. Also the libOSSlib.so library contains such 
> routines. If an OSS application is compiled without -DOSSLIB then they are 
> defined as open, etc. Unfortunately this version of soundcard.h was not 
> accepted by the kernel OSS maintainers so the stock Linux version doesn't 
> have these definitions.
> 
> If you like to get OSS apps to go through this library API you can do the 
> following:
> 
> - Get the latest soundcard.h from our OSS package to be included in the 
> stock kernel.
> - Do the same for libOSSlib (sources shipped with OSS).
> - Tell all OSS developers to change all OSS system calls to use their 
> osslib_ counterparts. And to recompile against the latest soundcard.h
> with -DOSSLIB. Make sure all distributions have done the changes before 
> that.
> 
> Then you can include a libOSSlib.o library in ALSA with all the OSS 
> emulation stuf inside.

You should do the clear statement that the direct using of syscalls is not 
recommented for application developers. Unfortunately at this time, I 
admit, it would be very difficult to change the existing applications.

I can only suggest to OSS including the commercial version:

1) create a osslib package under GPL and probably also under BSD licence
2) notify developers in your documentation that every syscall has own
   function in osslib and that using syscalls directly is not recommended

In this way, your library will go to all Linux distributions and OSS app 
developers will have quite confirmed the right direction from you.

						Jaroslav

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


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

On Tue, 10 Jan 2006, Jaroslav Kysela wrote:

> > 
> > Then you can include a libOSSlib.o library in ALSA with all the OSS 
> > emulation stuf inside.
> 
> You should do the clear statement that the direct using of syscalls is not 
> recommented for application developers. Unfortunately at this time, I 
> admit, it would be very difficult to change the existing applications.
Sorry. That breaks backward compatibility with systems that don't have 
libOSSlib (all current and past Linux distros, all BSD variants, 
everything but systems with our official OSS package installed). Such 
statement can be added in 2010 but provided that all Linux distros and 
other environments having OSS compatible implementations add the osslib_* 
routines within this year.

Best regards,

Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

On Tue, 10 Jan 2006, Hannu Savolainen wrote:

> On Tue, 10 Jan 2006, Jaroslav Kysela wrote:
> 
> > > 
> > > Then you can include a libOSSlib.o library in ALSA with all the OSS 
> > > emulation stuf inside.
> > 
> > You should do the clear statement that the direct using of syscalls is not 
> > recommented for application developers. Unfortunately at this time, I 
> > admit, it would be very difficult to change the existing applications.

> Sorry. That breaks backward compatibility with systems that don't have 
> libOSSlib (all current and past Linux distros, all BSD variants, 
> everything but systems with our official OSS package installed). Such 
> statement can be added in 2010 but provided that all Linux distros and 
> other environments having OSS compatible implementations add the osslib_* 
> routines within this year.

I meant that you can originate to move the OSS entry point to somewhere 
else (library) and try to persuade developers to use library than direct 
calls.

Of course, we cannot change current applications, but we can start the 
movement now. I just ask you to do it now. Nothing else. It will be a slow 
process but it should be started now.

Also, I don't think that it will break something. The application 
developers can use your code in their applications directly when the 
distribution does not have the OSS access library package.

Note that your words clearly states your attitude to change something.

						Jaroslav

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


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Re: [OT] ALSA userspace API complexity

[Adam Tlałka]

Dnia 10-01-2006 o 15:17:21 Jaroslav Kysela <perex@suse.cz> napisał:

> On Tue, 10 Jan 2006, Hannu Savolainen wrote:
>
>> On Tue, 10 Jan 2006, Jaroslav Kysela wrote:
>>
>> > >
>> > > Then you can include a libOSSlib.o library in ALSA with all the OSS
>> > > emulation stuf inside.
>> >
>> > You should do the clear statement that the direct using of syscalls  
>> is not
>> > recommented for application developers. Unfortunately at this time, I
>> > admit, it would be very difficult to change the existing applications.
>
>> Sorry. That breaks backward compatibility with systems that don't have
>> libOSSlib (all current and past Linux distros, all BSD variants,
>> everything but systems with our official OSS package installed). Such
>> statement can be added in 2010 but provided that all Linux distros and
>> other environments having OSS compatible implementations add the  
>> osslib_*
>> routines within this year.
>
> I meant that you can originate to move the OSS entry point to somewhere
> else (library) and try to persuade developers to use library than direct
> calls.
>
> Of course, we cannot change current applications, but we can start the
> movement now. I just ask you to do it now. Nothing else. It will be a  
> slow
> process but it should be started now.
>
> Also, I don't think that it will break something. The application
> developers can use your code in their applications directly when the
> distribution does not have the OSS access library package.
  ger atlka@sunrise.pg.gda.pl

Doing every call through some lib even if it's only a wrapper leading
to kernel syscall doesn't look very interesting.
Some people need statically lined apps and minimum usable distro without
bloated libs. What about Unix device abstraction?
Are we going the current Windows way?

Anyway Windows is stearing to the microkernel approach (approaching Vista)
and it looks that we are going to the current Windows model while MS  
developers
are going far away. Hurd looks nice but it is not good enough now.
But the idea is good and needs more people to improve it.

So we could have Unix device approach with drivers running as separate  
processes
not in kernel space. With proper kernel scheduling and being non-swappable
we could get good security, stability and additionally enough simple
 from app point of view approach. Going through libs we are going through
all the LD_PRELOAD and LD_LIBRARY_PATH and linker security hell.

Kernel approach looks good enough for me now. But it is not so secure of  
course.
So we need some process->kernel-device->driver RT/non-swappable/correctly
scheduled process IPC so we can do it the other way. IMHO that's the future
if we don't want drivers in the kernel.

Best regards
--
Adam Tlałka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdańsk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click