* Re: Re: The obsolence of OSS, Was: big smile
2004-02-25 11:20 ` Adam Tla/lka
@ 2004-02-25 11:40 ` Jan Depner
2004-02-25 11:53 ` Takashi Iwai
` (4 subsequent siblings)
5 siblings, 0 replies; 30+ messages in thread
From: Jan Depner @ 2004-02-25 11:40 UTC (permalink / raw)
To: Adam Tla/lka; +Cc: alsa-devel
Boy, I hate to step into the middle of a good screaming match ;-) but it
sounds to me like you're comparing apples and oranges. I run OSS at
work and ALSA at home. At work I just want to listen to tunes and run a
few different sound apps so OSS is fine. At home I'm doing multitrack
recording with pro gear so I *have* to have JACK/ALSA. OSS doesn't
handle my DSP2000 very well. In addition, almost all of the pro sound
apps are being written for JACK. From a normal user's point of view OSS
is probably smoother/easier/better. ALSA will eventually get there. I
*do* think that the decision to include ALSA in the kernel is probably
the beginning of the end for OSS (sorry).
Jan
On Wed, 2004-02-25 at 05:20, Adam Tla/lka wrote:
> On Tue, Feb 24, 2004 at 10:54:58PM +0100, Benno Senoner wrote:
> > for those that are too lazy to browse the forums:
> >
> > http://www.4front-tech.com/forum/viewtopic.php?t=25
> > -----
> > ....
> > far more advanced ???
> > Ok I'd like see Ardour runnnig with multiple 24bit cards, all the
> > switches for hardware monitoring etc under OSS.
> nice but many people just haven't this hardware and want to use
> normal PCI sound cards or even matherboard build in codecs
> and mix many applications PCM sound together, use MIDI (software
> emulated or not) without need of special configuring of aplications.
> VirtualMixer, InputMultiplexer and SoftMidi in OSS does things transparently.
> Mixing is done in kernel space so there is no delays and clicks
> while some disk activity get processor as occurs in ALSA mixing in lib
> case. Test xmms with ALSA and dma plugin and try to open big tar.gz
> file. We got buffer underrun and app freezes. Sometimes I can only do
> kill -9 ;-). It depends on buffer and period sizes. Sometimes app
> freezes completly and sometimes you can rebufer by pressing pause/play
> buttons. Is it nice and accepted?? While useing java app under aoss
> it gopes to hell if buffer underrun occures.
> >
> > How about MIDI ? Where is OSS' midi router, is there an ossconnect
> > utility ? (of course this a sarcastic comment :) )
> >
> should be done in the future ;-).
> >
> > Only a fool would write a new linux audio app that does not use ALSA,
> > especially apps that need MIDI.
> > Ok jackd will probably become the "audio interface" of choice, but jackd
> > using ALSA is more powerful than in the OSS case,
> > (talking of pure PCM based apps, with PCM/MIDI apps the advantage is
> > even more apparent).
> I don't know jackd in details but generally I don't want any additional
> suid daemon running in realtime priority in my system. Maybe if we need
> to pump sound streams through the net we need a daemon.
> But normally kernel should manage devices (real or emulated)
> so there is a consistent way of accessing and using them.
> I have many normal users which want to browse the net, display flash
> pages, java applets or use RealPlayer. All of them use OSS ;-).
>
> >
> > Not to mention that most distros once they will ship kernel 2.6 they
> > will probably use ALSA as default because users
> > are demanding multimedia features like MIDI, support of highend cards,
> OSS supports more cards then ALSA
>
> > jackd support etc.
> works with OSS too
>
> > So this will slowly but surely render OSS totally obsolete. I'm sorry
> > but that's the truth that you cannot escape from.
> Maybe but now functionalty of ALSA and just ease of use is not
> so good to satisfy us. Mixing in lib is bad in my opinion and works nice
> only if we have enough free CPU cycles. But we use many applications at
> the same time compiling kernel, transfering data, looking in the
> archives, doing backups etc.
>
> > Just like Micosoft's share on the desktop will drop considerably over
> > time due to linux being more efficient and cheaper :-)
> Not so fast :-(!!
>
> Regards
>
> --
> Adam Tla/lka mailto:atlka@pg.gda.pl ^v^ ^v^ ^v^
> System & Network Administration Group ~~~~~~
> Computer Center, Gdansk University of Technology, Poland
> PGP public key: finger atlka@sunrise.pg.gda.pl
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: Re: The obsolence of OSS, Was: big smile
2004-02-25 11:20 ` Adam Tla/lka
2004-02-25 11:40 ` Jan Depner
@ 2004-02-25 11:53 ` Takashi Iwai
2004-02-25 13:20 ` Adam Tla/lka
2004-02-25 17:48 ` Jussi Laako
2004-02-25 12:27 ` Måns Rullgård
` (3 subsequent siblings)
5 siblings, 2 replies; 30+ messages in thread
From: Takashi Iwai @ 2004-02-25 11:53 UTC (permalink / raw)
To: Alsa-devel
oh well, this thread can be a troll...
some points still to be noted:
- PCM mixing and software MIDI rendering in the kernel space are
evil. if you doubt it, ask on LKML :)
- xmms's throughput problem is because of implementation of ALSA
plugin. it has no intermediate buffer and no dedicated audio
thread.
it has nothing to do with the design of ALSA itself.
Takashi
At Wed, 25 Feb 2004 12:20:21 +0100,
Adam Tla/lka wrote:
>
> On Tue, Feb 24, 2004 at 10:54:58PM +0100, Benno Senoner wrote:
> > for those that are too lazy to browse the forums:
> >
> > http://www.4front-tech.com/forum/viewtopic.php?t=25
> > -----
> > ....
> > far more advanced ???
> > Ok I'd like see Ardour runnnig with multiple 24bit cards, all the
> > switches for hardware monitoring etc under OSS.
> nice but many people just haven't this hardware and want to use
> normal PCI sound cards or even matherboard build in codecs
> and mix many applications PCM sound together, use MIDI (software
> emulated or not) without need of special configuring of aplications.
> VirtualMixer, InputMultiplexer and SoftMidi in OSS does things transparently.
> Mixing is done in kernel space so there is no delays and clicks
> while some disk activity get processor as occurs in ALSA mixing in lib
> case. Test xmms with ALSA and dma plugin and try to open big tar.gz
> file. We got buffer underrun and app freezes. Sometimes I can only do
> kill -9 ;-). It depends on buffer and period sizes. Sometimes app
> freezes completly and sometimes you can rebufer by pressing pause/play
> buttons. Is it nice and accepted?? While useing java app under aoss
> it gopes to hell if buffer underrun occures.
> >
> > How about MIDI ? Where is OSS' midi router, is there an ossconnect
> > utility ? (of course this a sarcastic comment :) )
> >
> should be done in the future ;-).
> >
> > Only a fool would write a new linux audio app that does not use ALSA,
> > especially apps that need MIDI.
> > Ok jackd will probably become the "audio interface" of choice, but jackd
> > using ALSA is more powerful than in the OSS case,
> > (talking of pure PCM based apps, with PCM/MIDI apps the advantage is
> > even more apparent).
> I don't know jackd in details but generally I don't want any additional
> suid daemon running in realtime priority in my system. Maybe if we need
> to pump sound streams through the net we need a daemon.
> But normally kernel should manage devices (real or emulated)
> so there is a consistent way of accessing and using them.
> I have many normal users which want to browse the net, display flash
> pages, java applets or use RealPlayer. All of them use OSS ;-).
>
> >
> > Not to mention that most distros once they will ship kernel 2.6 they
> > will probably use ALSA as default because users
> > are demanding multimedia features like MIDI, support of highend cards,
> OSS supports more cards then ALSA
>
> > jackd support etc.
> works with OSS too
>
> > So this will slowly but surely render OSS totally obsolete. I'm sorry
> > but that's the truth that you cannot escape from.
> Maybe but now functionalty of ALSA and just ease of use is not
> so good to satisfy us. Mixing in lib is bad in my opinion and works nice
> only if we have enough free CPU cycles. But we use many applications at
> the same time compiling kernel, transfering data, looking in the
> archives, doing backups etc.
>
> > Just like Micosoft's share on the desktop will drop considerably over
> > time due to linux being more efficient and cheaper :-)
> Not so fast :-(!!
>
> Regards
>
> --
> Adam Tla/lka mailto:atlka@pg.gda.pl ^v^ ^v^ ^v^
> System & Network Administration Group ~~~~~~
> Computer Center, Gdansk University of Technology, Poland
> PGP public key: finger atlka@sunrise.pg.gda.pl
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
>
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: Re: The obsolence of OSS, Was: big smile
2004-02-25 11:53 ` Takashi Iwai
@ 2004-02-25 13:20 ` Adam Tla/lka
2004-02-25 17:48 ` Jussi Laako
1 sibling, 0 replies; 30+ messages in thread
From: Adam Tla/lka @ 2004-02-25 13:20 UTC (permalink / raw)
To: Takashi Iwai
On Wed, Feb 25, 2004 at 12:53:47PM +0100, Takashi Iwai wrote:
> oh well, this thread can be a troll...
maybe, but all this is for targeting your attention to some weak points
of ALSA ;-(. I am using ALSA on 2.6.3 kernel and testing it all the time.
> - PCM mixing and software MIDI rendering in the kernel space are
> evil. if you doubt it, ask on LKML :)
It's just my personal opinion. I am using ALSA mixing in lib and can
observe that this solution is not perfect. Also synchronizing PCM
streams at the sample position means that we couldn't use
MMX or other streaming CPU extensions to optimize mixing.
If you don't want kernel sound mixing then just don't load appropriate
module - and don't use it!! But I do need this possibility.
Generally we could have any device which needs adequate access timing
(video grabber, digital oscilloscope, etc..) so if we could have
appropriate designed kernel interface for this type of devices
using them would be easy. Now any of them need an additional suid daemon
process which is working in realtime. It is a security risk and deadlock
risk also. Generally there should be an ioctl in kernel by which process
could inform scheduler how often it wants to get CPU and how long should
it process its data. Now scheduler (read kernel) should decide if this is
possible to honour such request and treat it appropriatelly.
This approach could be applied to any critical data timing device
access not only sound ones. It is better general approach then working
on many deamon processes.
Also if a process is doing another open call on sound device it should get
additional virtual channel.
>
> - xmms's throughput problem is because of implementation of ALSA
> plugin. it has no intermediate buffer and no dedicated audio
> thread.
> it has nothing to do with the design of ALSA itself.
maybe but while using apps working with aoss in dma mode I could
observe same effect - badly written aoss-lib ;-) ?!
Regards
--
Adam Tla/lka mailto:atlka@pg.gda.pl ^v^ ^v^ ^v^
System & Network Administration Group ~~~~~~
Computer Center, Gdansk University of Technology, Poland
PGP public key: finger atlka@sunrise.pg.gda.pl
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Re: The obsolence of OSS, Was: big smile
2004-02-25 11:53 ` Takashi Iwai
2004-02-25 13:20 ` Adam Tla/lka
@ 2004-02-25 17:48 ` Jussi Laako
2004-02-25 18:41 ` Paul Davis
1 sibling, 1 reply; 30+ messages in thread
From: Jussi Laako @ 2004-02-25 17:48 UTC (permalink / raw)
To: Alsa-devel
On Wed, 2004-02-25 at 13:53, Takashi Iwai wrote:
> - PCM mixing and software MIDI rendering in the kernel space are
> evil. if you doubt it, ask on LKML :)
So is low-latency, LKML people made that clear also about year or two
back...
--
Jussi Laako <jussi.laako@pp.inet.fi>
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Re: The obsolence of OSS, Was: big smile
2004-02-25 17:48 ` Jussi Laako
@ 2004-02-25 18:41 ` Paul Davis
0 siblings, 0 replies; 30+ messages in thread
From: Paul Davis @ 2004-02-25 18:41 UTC (permalink / raw)
To: Jussi Laako; +Cc: Alsa-devel
>On Wed, 2004-02-25 at 13:53, Takashi Iwai wrote:
>
>> - PCM mixing and software MIDI rendering in the kernel space are
>> evil. if you doubt it, ask on LKML :)
>
>So is low-latency, LKML people made that clear also about year or two
>back...
on the contrary. they've made it very clear that its a goal that
linus, morton, molnar, love and several others all support
wholeheartedly. however, they do not agree on using a "quick fix"
approach to making it happen.
--p
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: The obsolence of OSS, Was: big smile
2004-02-25 11:20 ` Adam Tla/lka
2004-02-25 11:40 ` Jan Depner
2004-02-25 11:53 ` Takashi Iwai
@ 2004-02-25 12:27 ` Måns Rullgård
2004-02-25 18:58 ` Dan Hollis
2004-02-25 13:09 ` Jaroslav Kysela
` (2 subsequent siblings)
5 siblings, 1 reply; 30+ messages in thread
From: Måns Rullgård @ 2004-02-25 12:27 UTC (permalink / raw)
To: alsa-devel
Adam Tla/lka <atlka@pg.gda.pl> writes:
> Test xmms with ALSA and dma plugin and try to open big tar.gz
> file. We got buffer underrun and app freezes. Sometimes I can only
> do kill -9 ;-). It depends on buffer and period sizes. Sometimes app
> freezes completly and sometimes you can rebufer by pressing
> pause/play buttons. Is it nice and accepted??
XMMS is horribly broken.
--
Måns Rullgård
mru@kth.se
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: Re: The obsolence of OSS, Was: big smile
2004-02-25 12:27 ` Måns Rullgård
@ 2004-02-25 18:58 ` Dan Hollis
0 siblings, 0 replies; 30+ messages in thread
From: Dan Hollis @ 2004-02-25 18:58 UTC (permalink / raw)
To: Måns Rullgård; +Cc: alsa-devel
On Wed, 25 Feb 2004, Måns Rullgård wrote:
> Adam Tla/lka <atlka@pg.gda.pl> writes:
> > Test xmms with ALSA and dma plugin and try to open big tar.gz
> > file. We got buffer underrun and app freezes. Sometimes I can only
> > do kill -9 ;-). It depends on buffer and period sizes. Sometimes app
> > freezes completly and sometimes you can rebufer by pressing
> > pause/play buttons. Is it nice and accepted??
> XMMS is horribly broken.
xmms is broken even under oss...
-Dan
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Re: The obsolence of OSS, Was: big smile
2004-02-25 11:20 ` Adam Tla/lka
` (2 preceding siblings ...)
2004-02-25 12:27 ` Måns Rullgård
@ 2004-02-25 13:09 ` Jaroslav Kysela
2004-02-25 13:37 ` Adam Tla/lka
2004-02-25 13:42 ` Re: The obsolence of OSS, Was: big smile James Courtier-Dutton
2004-02-25 14:03 ` Giuliano Pochini
5 siblings, 1 reply; 30+ messages in thread
From: Jaroslav Kysela @ 2004-02-25 13:09 UTC (permalink / raw)
To: Adam Tla/lka; +Cc: Alsa-devel
On Wed, 25 Feb 2004, Adam Tla/lka wrote:
> On Tue, Feb 24, 2004 at 10:54:58PM +0100, Benno Senoner wrote:
> > for those that are too lazy to browse the forums:
> >
> > http://www.4front-tech.com/forum/viewtopic.php?t=25
> > -----
> > ....
> > far more advanced ???
> > Ok I'd like see Ardour runnnig with multiple 24bit cards, all the
> > switches for hardware monitoring etc under OSS.
> nice but many people just haven't this hardware and want to use
> normal PCI sound cards or even matherboard build in codecs
> and mix many applications PCM sound together, use MIDI (software
> emulated or not) without need of special configuring of aplications.
> VirtualMixer, InputMultiplexer and SoftMidi in OSS does things transparently.
> Mixing is done in kernel space so there is no delays and clicks
> while some disk activity get processor as occurs in ALSA mixing in lib
> case. Test xmms with ALSA and dma plugin and try to open big tar.gz
> file. We got buffer underrun and app freezes. Sometimes I can only do
> kill -9 ;-). It depends on buffer and period sizes. Sometimes app
It has nothing to do if the code is in user space or in kernel space.
You have a limited amount of CPU time. You cannot go beyond and we
continuously fix and improve our code. Doing mixing in interrupt is
very bad. The latency used with our lock-free algorithm is same as
with mixing in interrupt.
Personally, I am very satisfied with the dmix performance with recent
fixes. We need only a nice GUI tool to mantain the .asoundrc configuration
files so users can benefit with using of all extended functions.
> > Not to mention that most distros once they will ship kernel 2.6 they
> > will probably use ALSA as default because users
> > are demanding multimedia features like MIDI, support of highend cards,
> OSS supports more cards then ALSA
It's comparable and what we can do, if vendors does not co-operate with us
(no datasheets, information)? We are open world.
> so good to satisfy us. Mixing in lib is bad in my opinion and works nice
> only if we have enough free CPU cycles. But we use many applications at
> the same time compiling kernel, transfering data, looking in the
> archives, doing backups etc.
Nope. It has nothing to do with all above. With well-tuned system, you
will have same performance with both implementations.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: Re: The obsolence of OSS, Was: big smile
2004-02-25 13:09 ` Jaroslav Kysela
@ 2004-02-25 13:37 ` Adam Tla/lka
2004-02-25 14:17 ` Paul Davis
0 siblings, 1 reply; 30+ messages in thread
From: Adam Tla/lka @ 2004-02-25 13:37 UTC (permalink / raw)
To: Alsa-devel
On Wed, Feb 25, 2004 at 02:09:43PM +0100, Jaroslav Kysela wrote:
> It has nothing to do if the code is in user space or in kernel space.
> You have a limited amount of CPU time. You cannot go beyond and we
> continuously fix and improve our code. Doing mixing in interrupt is
> very bad. The latency used with our lock-free algorithm is same as
> with mixing in interrupt.
I don't think so. If an sound app is swapped out or another app is doing
intensive disk IO we could observe - hear - the difference.
aoss app can even stop and crash, some native ALSA apps too.
Maybe they are badly designed. Generally if the kernel know about time
critical app it can schedule them at appropriate time.
And this could be done only by kernel. Some apps colud run slower
and it should be acceptable - compilation or file copying for example.
> Personally, I am very satisfied with the dmix performance with recent
> fixes. We need only a nice GUI tool to mantain the .asoundrc configuration
> files so users can benefit with using of all extended functions.
I am raher satisfied too, with minor exceptions.
> Nope. It has nothing to do with all above. With well-tuned system, you
> will have same performance with both implementations.
I have low latency option on and some disk io optimiztions turned on too
but can easily observe buffer underrun and ALSA aoss app failure
by doing high CPU and disk IO operation - opening 500MB tar.gz file
for example.
Regards
--
Adam Tla/lka mailto:atlka@pg.gda.pl ^v^ ^v^ ^v^
System & Network Administration Group ~~~~~~
Computer Center, Gdansk University of Technology, Poland
PGP public key: finger atlka@sunrise.pg.gda.pl
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Re: The obsolence of OSS, Was: big smile
2004-02-25 13:37 ` Adam Tla/lka
@ 2004-02-25 14:17 ` Paul Davis
2004-02-25 14:50 ` Re: The obsolence of OSS, Was: big smiley Adam Tla/lka
0 siblings, 1 reply; 30+ messages in thread
From: Paul Davis @ 2004-02-25 14:17 UTC (permalink / raw)
To: Adam Tla/lka; +Cc: Alsa-devel
>I don't think so. If an sound app is swapped out or another app is doing
>intensive disk IO we could observe - hear - the difference.
and how can OSS help with that? ok, so we know that non-SCHED_FIFO
apps (and occasionally, even them) can be delayed by kernel-side
issues. but not keeping up with the device is not keeping up with the
device, no matter what the cause or API in use. OSS cannot mix in the
kernel unless user space has provided the data to mix.
>aoss app can even stop and crash, some native ALSA apps too.
>Maybe they are badly designed. Generally if the kernel know about time
>critical app it can schedule them at appropriate time.
>And this could be done only by kernel. Some apps colud run slower
>and it should be acceptable - compilation or file copying for example.
There are only 2 differences associated with running the code you are
talking about in the kernel:
a) it runs deterministically in interrupt context
b) it avoids a context switch back into user space
Linux is designed to make the context switch code very, very fast - if
it wasn't, then a system like JACK just could not work because it too
relies on context switches to make things happen.
The linux kernel community has long seen the kernel as a place to
avoid putting any functionality that can be provided in user
space. And the evidence is there that it *can* be provided in user
space.
The problems that you describe with existing apps is because many,
many, many existing apps are incorrectly designed. This is (IMHO)
because the APIs historically in use for Unix have encouraged
developers to ignore the real time nature of the devices they are
interacting with. They have done so by providing lots and lots of
buffering which has, till recently, been an adequate way to gloss over
the programs' problematic design. But it has now become a desirable
thing to be able to deliver audio with low latency, and this requires
a significant reduction in the buffering offered by the both the
hardware and the software layers above it (including the device
drivers). When this happens, it becomes apparent just how non-realtime
friendly most application designs are.
You can see exactly the same thing on Windows, where the MME model for
audio programming tends to produce programs that click and pop,
whereas those designed around ASIO and similar APIs do not (until
there is no alternative).
There are no shortcuts to click-free audio: either you do a lot of
buffering or you design your application so that it is RT-safe, or at
the very least based on an RT-friendly model.
>I have low latency option on and some disk io optimiztions turned on too
>but can easily observe buffer underrun and ALSA aoss app failure
>by doing high CPU and disk IO operation - opening 500MB tar.gz file
>for example.
sigh. of course! because the kernel has no idea that your audio
application needs to run with real-time priority, and is instead
treating all apps as if they are normal interactive programs. if you
tell the kernel that your app needs to run with RT priority (there are
various ways to do so), this doesn't happen (unless you so overload
the system that there is no way to keep up, but that requires quite a
lot). On a reasonable system (i.e. no interference from the video
card, sensible disk drivers etc), you can totally saturate the CPU and
disk subsystem with absolutely no audio dropouts.
OSS cannot affect this in any way - its a function of the kernel
scheduler and not the audio device API.
--p
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Re: The obsolence of OSS, Was: big smiley
2004-02-25 14:17 ` Paul Davis
@ 2004-02-25 14:50 ` Adam Tla/lka
2004-02-25 15:12 ` Takashi Iwai
` (2 more replies)
0 siblings, 3 replies; 30+ messages in thread
From: Adam Tla/lka @ 2004-02-25 14:50 UTC (permalink / raw)
To: Alsa-devel
On Wed, Feb 25, 2004 at 09:17:54AM -0500, Paul Davis wrote:
> There are only 2 differences associated with running the code you are
> talking about in the kernel:
>
> a) it runs deterministically in interrupt context
> b) it avoids a context switch back into user space
It could be more optimized too.
> Linux is designed to make the context switch code very, very fast - if
> it wasn't, then a system like JACK just could not work because it too
> relies on context switches to make things happen.
Next userspace daemon, then alsa-oss lib which could be swapped too.
> The linux kernel community has long seen the kernel as a place to
> avoid putting any functionality that can be provided in user
> space. And the evidence is there that it *can* be provided in user
> space.
Of course we could done device drivers in userspace too ;-)).
alsa-oss is some kind of virtual device, isn't it?
Maybe we need to change to microkernel approach??
> drivers). When this happens, it becomes apparent just how non-realtime
> friendly most application designs are.
Yes that's true. So some kernel support for time critical apps
should appear - not quite RT.
> You can see exactly the same thing on Windows, where the MME model for
> audio programming tends to produce programs that click and pop,
> whereas those designed around ASIO and similar APIs do not (until
> there is no alternative).
Agree.
> sigh. of course! because the kernel has no idea that your audio
> application needs to run with real-time priority, and is instead
> treating all apps as if they are normal interactive programs. if you
> tell the kernel that your app needs to run with RT priority (there are
So why I think about some api to tell the kernel that some app nedds CPU
in more deterministic manner. Generally if we could do this by /proc too
like tunnig ALSA for particular programs it would be good for old
proprietary programs which we couldn't improve.
It's not RT but some sheduler modification to treat some programs
specially.
> OSS cannot affect this in any way - its a function of the kernel
> scheduler and not the audio device API.
OK but we could have some kernel RT thread which is doing mixing
or MIDI emulation.
Regards
--
Adam Tla/lka mailto:atlka@pg.gda.pl ^v^ ^v^ ^v^
System & Network Administration Group ~~~~~~
Computer Center, Gdansk University of Technology, Poland
PGP public key: finger atlka@sunrise.pg.gda.pl
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: Re: The obsolence of OSS, Was: big smiley
2004-02-25 14:50 ` Re: The obsolence of OSS, Was: big smiley Adam Tla/lka
@ 2004-02-25 15:12 ` Takashi Iwai
2004-02-25 15:12 ` Paul Davis
2004-02-25 15:20 ` James Courtier-Dutton
2 siblings, 0 replies; 30+ messages in thread
From: Takashi Iwai @ 2004-02-25 15:12 UTC (permalink / raw)
To: Adam Tla/lka; +Cc: Alsa-devel
At Wed, 25 Feb 2004 15:50:20 +0100,
Adam Tla/lka wrote:
>
> > OSS cannot affect this in any way - its a function of the kernel
> > scheduler and not the audio device API.
> OK but we could have some kernel RT thread which is doing mixing
> or MIDI emulation.
if you start a thread, why it's needed to be a kernel thread at all?
besides, you cannot use MMX/SSE/etc in kernel threads, which you
wanted.
Takashi
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Re: The obsolence of OSS, Was: big smiley
2004-02-25 14:50 ` Re: The obsolence of OSS, Was: big smiley Adam Tla/lka
2004-02-25 15:12 ` Takashi Iwai
@ 2004-02-25 15:12 ` Paul Davis
2004-02-25 15:20 ` James Courtier-Dutton
2 siblings, 0 replies; 30+ messages in thread
From: Paul Davis @ 2004-02-25 15:12 UTC (permalink / raw)
To: Adam Tla/lka; +Cc: Alsa-devel
>On Wed, Feb 25, 2004 at 09:17:54AM -0500, Paul Davis wrote:
>> There are only 2 differences associated with running the code you are
>> talking about in the kernel:
>>
>> a) it runs deterministically in interrupt context
>> b) it avoids a context switch back into user space
>It could be more optimized too.
how can it be more optimized? code is code is code. there is no
difference (for the purposes under discussion) between kernel code and
user space code. oh, except that user space code can use the FPU which
for mixing can sometimes be pretty useful (though not essential).
>> Linux is designed to make the context switch code very, very fast - if
>> it wasn't, then a system like JACK just could not work because it too
>> relies on context switches to make things happen.
>Next userspace daemon, then alsa-oss lib which could be swapped too.
look, *any* process can be swapped, but any process can also lock all
its memory in place just like the kernel. admittedly, some priviledges
are required for this, and we (the linux audio community) are working
on ways to make this happen more easily. JACK already supports this -
when you run JACK in realtime mode, you (JACK and its clients)
*cannot* be swapped, ever.
>> drivers). When this happens, it becomes apparent just how non-realtime
>> friendly most application designs are.
>Yes that's true. So some kernel support for time critical apps
>should appear - not quite RT.
no, RT. audio interfaces are real-time devices. there is no fallback
if the s/w fails to keep up. and unlike with video, the human
perceptual system detects failures to keep up very easily.
>> sigh. of course! because the kernel has no idea that your audio
>> application needs to run with real-time priority, and is instead
>> treating all apps as if they are normal interactive programs. if you
>> tell the kernel that your app needs to run with RT priority (there are
>So why I think about some api to tell the kernel that some app nedds CPU
>in more deterministic manner. Generally if we could do this by /proc too
there is already such an API. its consists of:
sched_setparam (2)
mlock (2)
mlockall (2)
this API is portable to any POSIX operating system. its not a deadline
scheduler, which OS X has because of its Mach roots, but its a
suitable alternative IMHO.
>like tunnig ALSA for particular programs it would be good for old
>proprietary programs which we couldn't improve.
"man run" [ it exists on fedora core 1, but is an old program].
there are new versions of the same idea, givertcap and others.
>It's not RT but some sheduler modification to treat some programs
>specially.
it *IS* RT.
>> OSS cannot affect this in any way - its a function of the kernel
>> scheduler and not the audio device API.
>OK but we could have some kernel RT thread which is doing mixing
>or MIDI emulation.
there are no kernel RT threads. there is interrupt context, and there
is everything else, in which kernel threads are scheduled in just the
same way as all other threads.
--p
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: Re: The obsolence of OSS, Was: big smiley
2004-02-25 14:50 ` Re: The obsolence of OSS, Was: big smiley Adam Tla/lka
2004-02-25 15:12 ` Takashi Iwai
2004-02-25 15:12 ` Paul Davis
@ 2004-02-25 15:20 ` James Courtier-Dutton
2004-02-25 15:37 ` Paul Davis
2 siblings, 1 reply; 30+ messages in thread
From: James Courtier-Dutton @ 2004-02-25 15:20 UTC (permalink / raw)
To: Adam Tla/lka; +Cc: Alsa-devel
Adam Tla/lka wrote:
>
>>sigh. of course! because the kernel has no idea that your audio
>>application needs to run with real-time priority, and is instead
>>treating all apps as if they are normal interactive programs. if you
>>tell the kernel that your app needs to run with RT priority (there are
>
> So why I think about some api to tell the kernel that some app nedds CPU
> in more deterministic manner. Generally if we could do this by /proc too
> like tunnig ALSA for particular programs it would be good for old
> proprietary programs which we couldn't improve.
> It's not RT but some sheduler modification to treat some programs
> specially.
>
>
>
>>OSS cannot affect this in any way - its a function of the kernel
>>scheduler and not the audio device API.
>
> OK but we could have some kernel RT thread which is doing mixing
> or MIDI emulation.
>
> Regards
The ideal scheduler for realtime apps would be one that has an api that
allows for a call like "schedule me at exactly 10ms intervals+-1ms".
This would cause the scheduler to automatically juggle the other
processes around so that at the exact time of the 10ms interval, our
process gets CPU time. We would have to also configure +-ms so that the
scheduler has some leaway to allow for some optimisations.
This api should be flexible enough to allow us to do the same, but using
the sound card's hardware clock as the trigger.
The same again for the video card's clock/frame interrupt.
The current schedular gives every process X microseconds of CPU time or
less (process calls nano_sleep() )
We should be able to get the schedular to give a process less CPU time
if the next process to schedule is the realtime interval process.
Cheers
James
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Re: The obsolence of OSS, Was: big smiley
2004-02-25 15:20 ` James Courtier-Dutton
@ 2004-02-25 15:37 ` Paul Davis
2004-02-25 16:03 ` James Courtier-Dutton
0 siblings, 1 reply; 30+ messages in thread
From: Paul Davis @ 2004-02-25 15:37 UTC (permalink / raw)
To: James Courtier-Dutton; +Cc: Adam Tla/lka, Alsa-devel
>The ideal scheduler for realtime apps would be one that has an api that
>allows for a call like "schedule me at exactly 10ms intervals+-1ms".
no, thats not true.
the system clock does not run in sync with the sample clock. the drift
in this would become noticeable in a few minutes.
the only time to run an audio app is ASAP after the interrupt from the
device is recieved (assuming minimum latency; there is a more
involved, but still interrupt-driven deadline with non-minimal
latency).
--p
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Re: The obsolence of OSS, Was: big smiley
2004-02-25 15:37 ` Paul Davis
@ 2004-02-25 16:03 ` James Courtier-Dutton
2004-02-25 16:10 ` Paul Davis
2004-02-25 16:12 ` Paul Davis
0 siblings, 2 replies; 30+ messages in thread
From: James Courtier-Dutton @ 2004-02-25 16:03 UTC (permalink / raw)
To: Paul Davis; +Cc: Adam Tla/lka, Alsa-devel
Paul Davis wrote:
>>The ideal scheduler for realtime apps would be one that has an api that
>>allows for a call like "schedule me at exactly 10ms intervals+-1ms".
>
>
> no, thats not true.
>
> the system clock does not run in sync with the sample clock. the drift
> in this would become noticeable in a few minutes.
I know that. I was saying that we should be able to use the sample clock
in scheduling descisions as well as the system clock, but as you say,
for sound, we don't really care about the sample clock, only the
interrupt that happens as a result.
It would still be nice to have a system clock based interval process for
applications that require activity at specific intervals, but are not to
do with sound or video.
>
> the only time to run an audio app is ASAP after the interrupt from the
> device is recieved (assuming minimum latency; there is a more
> involved, but still interrupt-driven deadline with non-minimal
> latency).
>
> --p
>
An audio hardware interrupt can interrupt any process at any time.
Is there already a procedure in linux so that the interrupt_handler can
cause the scheduler to select a particular process to run immeadiately
after this interrupt_handler has finished?
I can see problems with the following setup: -
Audio interrupt occurs
Audio interrupt_handler finishes.
Audio user space process get control of CPU.
Some other interrupt occurs
Some other interrupt_handler informs the scheduler to run xyz process next.
Question: -
Which process should be run next?
Continue with the audio user space process, or start the new xyz process?
Cheers
James
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Re: The obsolence of OSS, Was: big smiley
2004-02-25 16:03 ` James Courtier-Dutton
@ 2004-02-25 16:10 ` Paul Davis
2004-02-25 16:12 ` Paul Davis
1 sibling, 0 replies; 30+ messages in thread
From: Paul Davis @ 2004-02-25 16:10 UTC (permalink / raw)
To: James Courtier-Dutton; +Cc: Adam Tla/lka, Alsa-devel
>It would still be nice to have a system clock based interval process for
>applications that require activity at specific intervals, but are not to
>do with sound or video.
i'd be interested to see a realistic usage case. its mostly related to
RT devices of some kind, most of which provide their own interrupt,
and they expect to be serviced ASAP wrt the interrupt.
>An audio hardware interrupt can interrupt any process at any time.
>Is there already a procedure in linux so that the interrupt_handler can
>cause the scheduler to select a particular process to run immeadiately
>after this interrupt_handler has finished?
of course. this is what SCHED_FIFO is all about, plus the lowlat
patches. conditional_reschedule() checks to see if a highpri process
has been marked runnable, and if so, switches to it (or rather, makes
sure that the return to user space returns to the new process).
>I can see problems with the following setup: -
>Audio interrupt occurs
>Audio interrupt_handler finishes.
>Audio user space process get control of CPU.
>Some other interrupt occurs
>Some other interrupt_handler informs the scheduler to run xyz process next.
>Question: -
>Which process should be run next?
>Continue with the audio user space process, or start the new xyz process?
its all about sched priority. SCHED_FIFO is top of the pile, and
within that, highest priority wins. SCHED_RR is next (sort of), and
then regular scheduling (SCHED_OTHER) after that.
if you run audio apps with JACK, the right thing will happen 99.9999%
of the time. the tiny percentage that it doesn't is caused by kernel
bugs (if it happens at all).
--p
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Re: The obsolence of OSS, Was: big smiley
2004-02-25 16:03 ` James Courtier-Dutton
2004-02-25 16:10 ` Paul Davis
@ 2004-02-25 16:12 ` Paul Davis
1 sibling, 0 replies; 30+ messages in thread
From: Paul Davis @ 2004-02-25 16:12 UTC (permalink / raw)
To: James Courtier-Dutton; +Cc: Adam Tla/lka, Alsa-devel
>It would still be nice to have a system clock based interval process for
>applications that require activity at specific intervals, but are not to
>do with sound or video.
have any actual use cases?
>An audio hardware interrupt can interrupt any process at any time.
>Is there already a procedure in linux so that the interrupt_handler can
>cause the scheduler to select a particular process to run immeadiately
>after this interrupt_handler has finished?
of course. that's what conditional_reschedule() is all about. it
checks to see if any process of higher priority than the current one
has been marked runnable, and switches to it if so.
>I can see problems with the following setup: -
>Audio interrupt occurs
>Audio interrupt_handler finishes.
>Audio user space process get control of CPU.
>Some other interrupt occurs
>Some other interrupt_handler informs the scheduler to run xyz process next.
>Question: -
>Which process should be run next?
>Continue with the audio user space process, or start the new xyz process?
its all about scheduler priority. SCHED_FIFO is top dog, ranked by
priority within that. SCHED_RR is sort-of-next, again by priority, and
then finally SCHED_OTHER.
if you run apps under JACK with the -R option, the right thing will happen.
--p
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Re: The obsolence of OSS, Was: big smile
2004-02-25 11:20 ` Adam Tla/lka
` (3 preceding siblings ...)
2004-02-25 13:09 ` Jaroslav Kysela
@ 2004-02-25 13:42 ` James Courtier-Dutton
2004-02-25 14:03 ` Giuliano Pochini
5 siblings, 0 replies; 30+ messages in thread
From: James Courtier-Dutton @ 2004-02-25 13:42 UTC (permalink / raw)
To: Adam Tla/lka; +Cc: Alsa-devel
Adam Tla/lka wrote:
>
> nice but many people just haven't this hardware and want to use
> normal PCI sound cards or even matherboard build in codecs
> and mix many applications PCM sound together, use MIDI (software
> emulated or not) without need of special configuring of aplications.
> VirtualMixer, InputMultiplexer and SoftMidi in OSS does things transparently.
> Mixing is done in kernel space so there is no delays and clicks
> while some disk activity get processor as occurs in ALSA mixing in lib
> case. Test xmms with ALSA and dma plugin and try to open big tar.gz
> file. We got buffer underrun and app freezes. Sometimes I can only do
> kill -9 ;-). It depends on buffer and period sizes. Sometimes app
> freezes completly and sometimes you can rebufer by pressing pause/play
> buttons. Is it nice and accepted?? While useing java app under aoss
> it gopes to hell if buffer underrun occures.
>
To be fair, xmms's alsa support is rather poor.
If you get the same problems with an application like xine
(xine.sf.net), then we would need to look into the problem. xine has
better alsa support than xmms.
Summary: -
Make the test fair. :-)
Cheers
James
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: Re: The obsolence of OSS, Was: big smile
2004-02-25 11:20 ` Adam Tla/lka
` (4 preceding siblings ...)
2004-02-25 13:42 ` Re: The obsolence of OSS, Was: big smile James Courtier-Dutton
@ 2004-02-25 14:03 ` Giuliano Pochini
5 siblings, 0 replies; 30+ messages in thread
From: Giuliano Pochini @ 2004-02-25 14:03 UTC (permalink / raw)
To: Adam Tla/lka; +Cc: Alsa-devel
On 25-Feb-2004 Adam Tla/lka wrote:
> On Tue, Feb 24, 2004 at 10:54:58PM +0100, Benno Senoner wrote:
>> for those that are too lazy to browse the forums:
>>
>> http://www.4front-tech.com/forum/viewtopic.php?t=25
>> -----
>> ....
>> far more advanced ???
>> Ok I'd like see Ardour runnnig with multiple 24bit cards, all the
>> switches for hardware monitoring etc under OSS.
> nice but many people just haven't this hardware and want to use
> normal PCI sound cards or even matherboard build in codecs
> and mix many applications PCM sound together [...]
Actually, I have far less xruns with ALSA than OSS. Are you sure the
buffer has the same length ? Otherwise the comparison is unfair. The
tar test does measure mainly the quality of the VM subsystem and the
speed of the harddisk. The sound stops because the application runs
out of data to play because the disk is busy. If the app freezes it
means there are bugs somewhere.
And yes, OSS is simpler for the end user because it has far more
features and it's not flexible. It's the Windows philosophy :))
>> So this will slowly but surely render OSS totally obsolete. I'm
>> sorry but that's the truth that you cannot escape from.
> Maybe but now functionalty of ALSA and just ease of use is not
> so good to satisfy us. Mixing in lib is bad in my opinion and works nice
> only if we have enough free CPU cycles. But we use many applications at
> the same time compiling kernel, transfering data, looking in the
> archives, doing backups etc.
The code that runs inside the kernel doesn't execute faster. Instead,
you have far less control over it and it can cause high latencies.
And about the cuckoo thing, it's an ALSA-over-OSS frankenstein monster
that cannot be as good as both OSS or ALSA alone. They're trying to
keep OSS alive as long as they can.
--
Giuliano.
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
^ permalink raw reply [flat|nested] 30+ messages in thread