big smile

big smile

[Jaroslav Kysela]

http://www.opensound.com/cuckoo.html

:-) No comment, except that some comments are really wrong.

						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

Re: big smile

[Peter Antypas]

This is directly equivalent to Intel's decision to follow AMD on the 64-bit
trail ... they will lose big if they don't.


----- Original Message ----- 
From: "Jaroslav Kysela" <perex@suse.cz>
To: "ALSA development" <alsa-devel@alsa-project.org>
Sent: Tuesday, February 24, 2004 7:47 AM
Subject: [Alsa-devel] big smile


>
> http://www.opensound.com/cuckoo.html
>
> :-) No comment, except that some comments are really wrong.
>
> 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
> _______________________________________________
> 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

Re: big smile

[James Courtier-Dutton]

Jaroslav Kysela wrote:
> http://www.opensound.com/cuckoo.html
> 
> :-) No comment, except that some comments are really wrong.
> 
> 						Jaroslav
> 

Hehe! ;-)

Is there a list anywhere listing the differences between OSS and ALSA 
with regard to sound card hardware.
It would be nice to have a nice small list of all the sound hardware OSS 
supports, but ALSA does not.
Then the intention would be to reduce that list to no entries by 
implementing them all in ALSA.

I only know of 2 sound cards on that list: -
1) SB Live (Dell version) emu10k1x
2) SB Audigy LS (A emu10k1x lookalive with minor differences)

Are there any others we need to add to the list?

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

Re: big smile

[Jaroslav Kysela]

On Tue, 24 Feb 2004, James Courtier-Dutton wrote:

> Jaroslav Kysela wrote:
> > http://www.opensound.com/cuckoo.html
> > 
> > :-) No comment, except that some comments are really wrong.
> > 
> > 						Jaroslav
> > 
> 
> Hehe! ;-)
> 
> Is there a list anywhere listing the differences between OSS and ALSA 
> with regard to sound card hardware.
> It would be nice to have a nice small list of all the sound hardware OSS 
> supports, but ALSA does not.
> Then the intention would be to reduce that list to no entries by 
> implementing them all in ALSA.
> 
> I only know of 2 sound cards on that list: -
> 1) SB Live (Dell version) emu10k1x
> 2) SB Audigy LS (A emu10k1x lookalive with minor differences)

Yes, I definitely want to support these cards in ALSA in near future.
It seems that Creative is very popular here in Europe.

Also there are some lynxone, lynxtwo modules in latest OSS drivers.

						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

Re: big smile

[James Courtier-Dutton]

Jaroslav Kysela wrote:
> On Tue, 24 Feb 2004, James Courtier-Dutton wrote:
> 
> 
>>Jaroslav Kysela wrote:
>>
>>>http://www.opensound.com/cuckoo.html
>>>
>>>:-) No comment, except that some comments are really wrong.
>>>
>>>						Jaroslav
>>>
>>
>>Hehe! ;-)
>>
>>Is there a list anywhere listing the differences between OSS and ALSA 
>>with regard to sound card hardware.
>>It would be nice to have a nice small list of all the sound hardware OSS 
>>supports, but ALSA does not.
>>Then the intention would be to reduce that list to no entries by 
>>implementing them all in ALSA.
>>
>>I only know of 2 sound cards on that list: -
>>1) SB Live (Dell version) emu10k1x
>>2) SB Audigy LS (A emu10k1x lookalive with minor differences)
> 
> 
> Yes, I definitely want to support these cards in ALSA in near future.
> It seems that Creative is very popular here in Europe.
> 
> Also there are some lynxone, lynxtwo modules in latest OSS drivers.
> 
> 						Jaroslav
> 

Can we add them in RED to the http://www.alsa-project.org/alsa-doc/  page?

SB Live (Dell version) emu10k1x: -
(lspci would give "Class 0401: 1102:0006")
SB Audigy LS (A emu10k1x lookalike with minor differences.)
(lspci would give "Class 0401: 1102:0007")

Maybe we should add an lspci info column to the table, so people could 
quickly see if their card was supported or not.

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

Re: big smile

[Mihai T. Lazarescu]

I'd add also Yamaha YMF-744B [DS-1S Audio Controller] --
on Toshiba Tecra 8100 laptops -- that used to work with ALSA
0.5 but works randomly with newer versions.  The OSS drivers
are fine. :)

Cheers,

Mihai

On Tue, 24 Feb 2004, James Courtier-Dutton wrote:

> Is there a list anywhere listing the differences between OSS and ALSA 
> with regard to sound card hardware.
> It would be nice to have a nice small list of all the sound hardware OSS 
> supports, but ALSA does not.
> Then the intention would be to reduce that list to no entries by 
> implementing them all in ALSA.
> 
> I only know of 2 sound cards on that list: -
> 1) SB Live (Dell version) emu10k1x
> 2) SB Audigy LS (A emu10k1x lookalive with minor differences)
> 
> Are there any others we need to add to the list?
> 
> 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
> _______________________________________________
> 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

Re: big smile

[Giuliano Pochini]

> > Is there a list anywhere listing the differences between OSS and ALSA
> > with regard to sound card hardware.
> > It would be nice to have a nice small list of all the sound hardware OSS
> > supports, but ALSA does not.
> > Then the intention would be to reduce that list to no entries by
> > implementing them all in ALSA.
> >
> > I only know of 2 sound cards on that list: -
> > 1) SB Live (Dell version) emu10k1x
> > 2) SB Audigy LS (A emu10k1x lookalive with minor differences)

LynxOne, LynxTwo, Lynx-L22, Lynx-AES16, which are the best peices of
sound hardware for a pc, as far as I know :(


--
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

Re: The obsolence of OSS, Was: big smile

[Benno Senoner]

for those that are too lazy to browse the forums:

http://www.4front-tech.com/forum/viewtopic.php?t=25
-----
.... We hope you can now show your ALSA friends how much better your OSS 
drivers sound and actually tell them that OSS isn't all that "old and 
obsolete". The fact that we can do a ALSA emulation implies that OSS is 
far more advanced than ALSA people give it credit.  ...
----

far more advanced ???
Ok I'd like see Ardour runnnig with multiple 24bit cards, all the 
switches for hardware monitoring etc under OSS.

How about MIDI ? Where is OSS' midi router, is there an ossconnect 
utility ? (of course this a sarcastic comment :) )


http://www.4front-tech.com/forum/viewtopic.php?t=4
----
.... One of our main observations is that the "driver" part of ALSA is 
actually just a 1:1 clone of OSS's low level driver interface but 
everything is rewritten from scratch. We have been able to get ALSA work 
with the low level drivers of (commercial) OSS without any changes to 
OSS itself. Everything can be done in a small module that is loaded 
after executing soundon and loading ALSA's snd-pcm module. This module 
will be released under GPL during this spring.

After this it will be possible to use ALSA applications together with 
OSS. So if you are an OSS customer you don't need to leave OSS to use 
ALSA. You can use proven OSS drivers and still be able to run the few 
ALSA only applications.
....
----
The FEW ALSA only applications ??

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).

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, 
jackd support etc.
So this will slowly but surely render OSS totally obsolete. I'm sorry 
but that's the truth that you cannot escape from.
Just like Micosoft's share on the desktop will drop considerably over 
time due to linux being more efficient and cheaper :-)

cheers,
Benno
http://www.linuxsampler.org



Jaroslav Kysela wrote:

>http://www.opensound.com/cuckoo.html
>
>:-) No comment, except that some comments are really wrong.
>
>						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
>_______________________________________________
>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

Re: Re: The obsolence of OSS, Was: big smile

[Adam Tla/lka]

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

Re: Re: The obsolence of OSS, Was: big smile

[Jan Depner]

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

Re: Re: The obsolence of OSS, Was: big smile

[Takashi Iwai]

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

Re: The obsolence of OSS, Was: big smile

[Måns Rullgård]

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

Re: Re: The obsolence of OSS, Was: big smile

[Jaroslav Kysela]

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

Re: Re: The obsolence of OSS, Was: big smile

[Adam Tla/lka]

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

Re: Re: The obsolence of OSS, Was: big smile

[Adam Tla/lka]

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

Re: Re: The obsolence of OSS, Was: big smile

[James Courtier-Dutton]

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

Re: Re: The obsolence of OSS, Was: big smile

[Giuliano Pochini]

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

Re: Re: The obsolence of OSS, Was: big smile

[Paul Davis]

>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

Re: Re: The obsolence of OSS, Was: big smiley

[Adam Tla/lka]

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

Re: Re: The obsolence of OSS, Was: big smiley

[Takashi Iwai]

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

Re: Re: The obsolence of OSS, Was: big smiley

[Paul Davis]

>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

Re: Re: The obsolence of OSS, Was: big smiley

[James Courtier-Dutton]

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

Re: Re: The obsolence of OSS, Was: big smiley

[Paul Davis]

>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

Re: Re: The obsolence of OSS, Was: big smiley

[James Courtier-Dutton]

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

Re: Re: The obsolence of OSS, Was: big smiley

[Paul Davis]

>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

Re: Re: The obsolence of OSS, Was: big smiley

[Paul Davis]

>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

Re: Re: The obsolence of OSS, Was: big smile

[Jussi Laako]

On Tue, 2004-02-24 at 23:54, Benno Senoner wrote:

> far more advanced ???
> Ok I'd like see Ardour runnnig with multiple 24bit cards, all the 
> switches for hardware monitoring etc under OSS.

At least I can play sound from application A to S/PDIF output and
simultaneously record input channels 1&2 on my Delta1010.

ALSA deadlocks the machine, OSS works.

> Only a fool would write a new linux audio app that does not use ALSA, 
> especially apps that need MIDI.

Well, I'm a fool then. I support OSS, ALSA, Comedi
(http://www.comedi.org/) and Jack in my apps.

Only fool writes app which runs only on Linux, and ALSA is currently
Linux-only. I want my app to run on FreeBSD, Solaris and others also.

> 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).

How's that for PCM?

> are demanding multimedia features like MIDI, support of highend cards, 
> jackd support etc.

OSS supports various "highend" cards, like Lynx Studio stuff.


I'm not saying that ALSA is bad, but just blindly bashing OSS isn't
doing any good for anyone.


-- 
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

Re: Re: The obsolence of OSS, Was: big smile

[Jussi Laako]

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

Re: Re: The obsolence of OSS, Was: big smile

[Paul Davis]

>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

Re: Re: The obsolence of OSS, Was: big smile

[Dan Hollis]

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