[ANNOUNCE] OSS Proxy using CUSE

[ANNOUNCE] OSS Proxy using CUSE

[Tejun Heo]

Hello again,

So, after all the fuss, here's the state-of-the-art standard-compliant
cloud-computing web-3.0-beta web page for OSS emulation using CUSE.

  http://userweb.kernel.org/~tj/ossp/

It works pretty well here.  :-)

Thanks.

-- 
tejun

Re: [ANNOUNCE] OSS Proxy using CUSE

[Adrian Bunk]

On Thu, Aug 28, 2008 at 09:05:53PM +0200, Tejun Heo wrote:
> Hello again,
> 
> So, after all the fuss, here's the state-of-the-art standard-compliant
> cloud-computing web-3.0-beta web page for OSS emulation using CUSE.
> 
>   http://userweb.kernel.org/~tj/ossp/
> 
> It works pretty well here.  :-)

Sorry for being destructive, but 6 years after ALSA went into the
kernel we are slightly approaching the point where all applications 
support ALSA.

The application you list on your webpage is UML host sound support,
and I'm wondering why you don't fix that instead of working on a
better OSS emulation?

> Thanks.
> tejun

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [ANNOUNCE] OSS Proxy using CUSE

[Greg KH]

On Thu, Aug 28, 2008 at 11:01:20PM +0300, Adrian Bunk wrote:
> On Thu, Aug 28, 2008 at 09:05:53PM +0200, Tejun Heo wrote:
> > Hello again,
> > 
> > So, after all the fuss, here's the state-of-the-art standard-compliant
> > cloud-computing web-3.0-beta web page for OSS emulation using CUSE.
> > 
> >   http://userweb.kernel.org/~tj/ossp/
> > 
> > It works pretty well here.  :-)
> 
> Sorry for being destructive, but 6 years after ALSA went into the
> kernel we are slightly approaching the point where all applications 
> support ALSA.
> 
> The application you list on your webpage is UML host sound support,
> and I'm wondering why you don't fix that instead of working on a
> better OSS emulation?

Independant of that, I can see a number of uses for the CUSE code.  One
would be emulating /dev/pilot for old palm pilot software that things it
wants to talk to a serial port, yet really a libusb userspace program
can handle all of the data to the USB device instead.

So don't think that just because this userspace-OSS implementation is
"not what should be done" that CUSE shouldn't be viable.

thanks,

greg k-h

Re: [ANNOUNCE] OSS Proxy using CUSE

[H. Peter Anvin]

Greg KH wrote:
> 
> Independant of that, I can see a number of uses for the CUSE code.  One
> would be emulating /dev/pilot for old palm pilot software that things it
> wants to talk to a serial port, yet really a libusb userspace program
> can handle all of the data to the USB device instead.
> 

I think that's probably another bad example... I would think serial port 
emulation would be better handled by ptys, and/or a specific serial port 
emulation module.

The big problem with using ptys for serial port emulation is that they 
currently don't handle BREAK at all.

	-hpa

Re: [ANNOUNCE] OSS Proxy using CUSE

[Greg KH]

On Thu, Aug 28, 2008 at 04:05:55PM -0700, H. Peter Anvin wrote:
> Greg KH wrote:
>> Independant of that, I can see a number of uses for the CUSE code.  One
>> would be emulating /dev/pilot for old palm pilot software that things it
>> wants to talk to a serial port, yet really a libusb userspace program
>> can handle all of the data to the USB device instead.
>
> I think that's probably another bad example... I would think serial port 
> emulation would be better handled by ptys, and/or a specific serial port 
> emulation module.

Hm, why?  It's a "fake" serial port as it is just a pass-through to the
USB device.  No flow control or line settings work on the device, so the
kernel driver just silently eats them.  But there is old, closed source
software that wants to talk to a serial port, so the kernel driver
remains.  With this code, we could then use the more modern libusb code
instead.

I guess you could hook it up through a pty, and somehow create
/dev/pilot/ for it as well, that is an idea to consider.

> The big problem with using ptys for serial port emulation is that they 
> currently don't handle BREAK at all.

For this type of USB device, that's not an issue :)

thanks,

greg k-h

Re: [ANNOUNCE] OSS Proxy using CUSE

[H. Peter Anvin]

Greg KH wrote:
> 
> Hm, why?  It's a "fake" serial port as it is just a pass-through to the
> USB device.  No flow control or line settings work on the device, so the
> kernel driver just silently eats them.  But there is old, closed source
> software that wants to talk to a serial port, so the kernel driver
> remains.  With this code, we could then use the more modern libusb code
> instead.
> 
> I guess you could hook it up through a pty, and somehow create
> /dev/pilot/ for it as well, that is an idea to consider.
> 

Why?  Because there is a lot of complexity in the tty layer, and there 
is no point in replicating the entire tty layer with all its ioctls 
through a fragile user-space emulator.  For cases like this, a pty is 
easier (your daemon opens /dev/ptmx, and then symlinks the appropriate 
pty to /dev/pilot) and works better.

>> The big problem with using ptys for serial port emulation is that they 
>> currently don't handle BREAK at all.
> 
> For this type of USB device, that's not an issue :)

Indeed.  It would be nice to fix, because it would make implementing 
serial ports as ptys+userspace a much more capable replacement.  It's 
not trivial, though, because the interpretation of the BREAK has to be 
done when received, not when sent, which means supporting a 257th value 
in the underlying buffer setup.

	-hpa

Re: [ANNOUNCE] OSS Proxy using CUSE

[Alan Cox]

> serial ports as ptys+userspace a much more capable replacement.  It's 
> not trivial, though, because the interpretation of the BREAK has to be 
> done when received, not when sent, which means supporting a 257th value 
> in the underlying buffer setup.

That bit of the problem is trivial. Its the rest of the behavioural
differences that are more of a nightmare - parity, flow control
differences, modem line emulation, being able to hook into things like
ldisc change/termios change.

Break is about a half hour job.

Alan

Re: [ANNOUNCE] OSS Proxy using CUSE

[Tejun Heo]

Adrian Bunk wrote:
> Sorry for being destructive, but 6 years after ALSA went into the
> kernel we are slightly approaching the point where all applications 
> support ALSA.

Yeah, I have to agree it's a bit too late but the exclusion between OSS
and more modern sound systems (be it ALSA or PA) still bugged me quite a
bit.  There always seems this one off app that wasn't quite there - be
it mpg123 for whatever reason I still enjoy to use from time to time,
vmware which is a genuine pain in the ass to get working with LD_PRELOAD
tricks (hopefully 6.5 will finally use ALSA but wait we're all going PA
now...) or scorch-3D (and many other games) where aoss delivers horrible
sound after playing for a while.

> The application you list on your webpage is UML host sound support,
> and I'm wondering why you don't fix that instead of working on a
> better OSS emulation?

Other than OSS emulation, CUSE seemed like an idea which might be able
to stand on its own legs, say, for legacy or proprietary device
emulation or just putting what used to be considered kernel-worthy to
userland.

Anyways, the thing is that unlike what was originally expected, dropping
an major programming API doesn't really work too well even after six
years of trying.  Maybe because OSS is still kicking on other unices.

We now have in-kernel OSS emulation which can't mux with other streams,
aoss with its own supported and broken list and can also be routed
through PA by configuring ALSA right and then padsp with its own
supported and broken list and nothing works good enough.  So, if we have
one thing which just works, we can in time put all those to rest.

Thanks.

-- 
tejun

Re: [ANNOUNCE] OSS Proxy using CUSE

[Adrian Bunk]

On Fri, Aug 29, 2008 at 03:33:14AM +0200, Tejun Heo wrote:
> Adrian Bunk wrote:
> > Sorry for being destructive, but 6 years after ALSA went into the
> > kernel we are slightly approaching the point where all applications 
> > support ALSA.
> 
> Yeah, I have to agree it's a bit too late but the exclusion between OSS
> and more modern sound systems (be it ALSA or PA) still bugged me quite a
> bit.  There always seems this one off app that wasn't quite there - be
> it mpg123 for whatever reason I still enjoy to use from time to time,

mpg123 supports ALSA since 1998 (sic).

> vmware which is a genuine pain in the ass to get working with LD_PRELOAD
> tricks (hopefully 6.5 will finally use ALSA but wait we're all going PA
> now...) or scorch-3D (and many other games) where aoss delivers horrible
> sound after playing for a while.

Scorched3D gives me sound with native ALSA.

Is your libSDL not linked with libasound?

>...
> Anyways, the thing is that unlike what was originally expected, dropping
> an major programming API doesn't really work too well even after six
> years of trying.

Good ALSA emulation was a hot topic a few years ago when popular 
software like Flash and Skype didn't support ALSA, but the use
cases are becoming rare.

2 out of your 3 examples above were software where native ALSA works,
but your distributions seems to ship you a setup where you thought 
OSS emulation was required.

Which distribution are you using whose makers seem to need
a big cluebat?

> Maybe because OSS is still kicking on other unices.

Which Unix with a big userbase uses OSS as primary sound system?

OSS-only applications tend to be older Linux-only applications.

Cross-platform applications either ship half a dozen different sound 
drivers (including ALSA), or more commonly use some library that offers
one API no matter which sound system gets used.

>...
> Thanks.
> tejun

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [ANNOUNCE] OSS Proxy using CUSE

[Tejun Heo]

Adrian Bunk wrote:
>> Yeah, I have to agree it's a bit too late but the exclusion between OSS
>> and more modern sound systems (be it ALSA or PA) still bugged me quite a
>> bit.  There always seems this one off app that wasn't quite there - be
>> it mpg123 for whatever reason I still enjoy to use from time to time,
> 
> mpg123 supports ALSA since 1998 (sic).

Heh.. I probably don't have the right plugin.  Oh... it has all the
plugins including pulse.  So, this one can be crossed off.

>> vmware which is a genuine pain in the ass to get working with LD_PRELOAD
>> tricks (hopefully 6.5 will finally use ALSA but wait we're all going PA
>> now...) or scorch-3D (and many other games) where aoss delivers horrible
>> sound after playing for a while.
> 
> Scorched3D gives me sound with native ALSA.
> 
> Is your libSDL not linked with libasound?

I'm not sure at all.  It was from openSUSE game repo back in 10.3
earlier this year and it only spoke OSS, but I bet if I try different
games in the current repo, I'll be able to find at least some which
still only work with OSS.

>> Anyways, the thing is that unlike what was originally expected, dropping
>> an major programming API doesn't really work too well even after six
>> years of trying.
> 
> Good ALSA emulation was a hot topic a few years ago when popular 
> software like Flash and Skype didn't support ALSA, but the use
> cases are becoming rare.
> 
> 2 out of your 3 examples above were software where native ALSA works,
> but your distributions seems to ship you a setup where you thought 
> OSS emulation was required.

Yeah, that's why I agree it's a bit too late but still better late than
never.  There are just some programs, be it commercial or ancient, which
don't work quite as well as it could.  Requiring update to ALSA took
painfully long years and we're still not in the clear yet.  Now should
we ask people to update to PA?

Then there's arch-um.  Yes, you can teach it to forward ALSA but then it
won't mux.  The only solution would be to link it against libalsa or
libpulse.

> Which distribution are you using whose makers seem to need
> a big cluebat?

openSUSE.  Not sure whether it deserves cluebat tho.

>> Maybe because OSS is still kicking on other unices.
> 
> Which Unix with a big userbase uses OSS as primary sound system?
> 
> OSS-only applications tend to be older Linux-only applications.
> 
> Cross-platform applications either ship half a dozen different sound 
> drivers (including ALSA), or more commonly use some library that offers
> one API no matter which sound system gets used.

Most major ones do, but there are programs and games which just haven't
fared off as well as more popular ones and thus just stopped being
updated and then there are commercial games which won't be updated in
any foreseeable future.  There are reasons why something as brand new as
pulse comes with something like padsp.

And it's not like CUSE adds whole lot to the kernel.  It mostly just
piggy backs on the existing FUSE.  Yeah, ioctl and poll are a bit
complex but with those and CUSE proper combined, it's way smaller than
the in-kernel ALSA OSS emulation which is somewhat painful to use these
days.

ossp is simply a better way to support /dev/dsp on modern systems and
bulk of it lives in userland (and I hope this can be the case for future
deprecations too).  If for nothing else, it'll enable us to do away with
three different emulations at the very least.  I mean we can't of course
do away with padsp and then some still only work with aoss and then we
need in-kernel ALSA OSS emulation as the final fallback when both fail.
 It's a big mess and ossp can basically OSS emulation as good as
in-kernel ALSA OSS w/ muxing.

Thanks.

-- 
tejun

Re: [ANNOUNCE] OSS Proxy using CUSE

[Miklos Szeredi]

On Fri, 29 Aug 2008, Tejun Heo wrote:
> Most major ones do, but there are programs and games which just haven't
> fared off as well as more popular ones and thus just stopped being
> updated and then there are commercial games which won't be updated in
> any foreseeable future.  There are reasons why something as brand new as
> pulse comes with something like padsp.

I have to agree with Tejun, there will always be old executables lying
around and source code that nobody will bother updating that still use
legacy interfaces.

I have a handful of programs that are still OSS only (one of them,
spectemu, being still popular enough to be in several major distros).

I could update them to alsa, but most of them I use once or twice a
year, it doesn't make sense.

In all the world there are probably thousands of such apps, and
porting each and every one to newer interfaces (if it could be done at
all) would probably be a much bigger effort then implementing a
backward compatibility layer for OSS.

Miklos

Re: [ANNOUNCE] OSS Proxy using CUSE

[Adrian Bunk]

On Fri, Aug 29, 2008 at 09:26:03AM +0200, Tejun Heo wrote:
> Adrian Bunk wrote:
>...
> >> Anyways, the thing is that unlike what was originally expected, dropping
> >> an major programming API doesn't really work too well even after six
> >> years of trying.
> > 
> > Good ALSA emulation was a hot topic a few years ago when popular 
> > software like Flash and Skype didn't support ALSA, but the use
> > cases are becoming rare.
> > 
> > 2 out of your 3 examples above were software where native ALSA works,
> > but your distributions seems to ship you a setup where you thought 
> > OSS emulation was required.
> 
> Yeah, that's why I agree it's a bit too late but still better late than
> never.  There are just some programs, be it commercial or ancient, which
> don't work quite as well as it could.  Requiring update to ALSA took
> painfully long years and we're still not in the clear yet.  Now should
> we ask people to update to PA?
>...

Doesn't PA already emulate ALSA?

> ossp is simply a better way to support /dev/dsp on modern systems and
> bulk of it lives in userland (and I hope this can be the case for future
> deprecations too).  If for nothing else, it'll enable us to do away with
> three different emulations at the very least.  I mean we can't of course
> do away with padsp and then some still only work with aoss and then we
> need in-kernel ALSA OSS emulation as the final fallback when both fail.
>  It's a big mess and ossp can basically OSS emulation as good as
> in-kernel ALSA OSS w/ muxing.

The in-kernel OSS emulation also support OSS MIDI.

> Thanks.
> tejun

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [ANNOUNCE] OSS Proxy using CUSE

[Tejun Heo]

Hello,

Adrian Bunk wrote:
>> Yeah, that's why I agree it's a bit too late but still better late than
>> never.  There are just some programs, be it commercial or ancient, which
>> don't work quite as well as it could.  Requiring update to ALSA took
>> painfully long years and we're still not in the clear yet.  Now should
>> we ask people to update to PA?
>> ...
> 
> Doesn't PA already emulate ALSA?

There's an ALSA plugin which connects to PA.  It works pretty well most
of the time although there are some odd ones which break.  Skype didn't
work too well a few months ago.  Dunno how it works these days tho and
it's likely that the next iteration of popular audio apps will do PA
directly.

>> ossp is simply a better way to support /dev/dsp on modern systems and
>> bulk of it lives in userland (and I hope this can be the case for future
>> deprecations too).  If for nothing else, it'll enable us to do away with
>> three different emulations at the very least.  I mean we can't of course
>> do away with padsp and then some still only work with aoss and then we
>> need in-kernel ALSA OSS emulation as the final fallback when both fail.
>>  It's a big mess and ossp can basically OSS emulation as good as
>> in-kernel ALSA OSS w/ muxing.
> 
> The in-kernel OSS emulation also support OSS MIDI.

Yeah, and adding midi support to ossp won't add one line of code to the
kernel.  :-)

Thanks.

-- 
tejun

Re: [ANNOUNCE] OSS Proxy using CUSE

[Pavel Machek]

Hi!

> > So, after all the fuss, here's the state-of-the-art standard-compliant
> > cloud-computing web-3.0-beta web page for OSS emulation using CUSE.
> > 
> >   http://userweb.kernel.org/~tj/ossp/
> > 
> > It works pretty well here.  :-)
> 
> Sorry for being destructive, but 6 years after ALSA went into the
> kernel we are slightly approaching the point where all applications 
> support ALSA.

Did ALSA reach a point where you can support new cards by just
updating the kernel?

I kind of like /dev/dsp interface... and don't see why simple sound
apps should be linked to libalsa... I used to record and play sounds
from shell by cat /dev/dsp...
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [ANNOUNCE] OSS Proxy using CUSE

[Jan Engelhardt]

On Thursday 2008-08-28 22:01, Adrian Bunk wrote:
>On Thu, Aug 28, 2008 at 09:05:53PM +0200, Tejun Heo wrote:
>> Hello again,
>> 
>> So, after all the fuss, here's the state-of-the-art standard-compliant
>> cloud-computing web-3.0-beta web page for OSS emulation using CUSE.
>> 
>>   http://userweb.kernel.org/~tj/ossp/
>> 
>> It works pretty well here.  :-)
>
>Sorry for being destructive, but 6 years after ALSA went into the
>kernel we are slightly approaching the point where all applications 
>support ALSA.

Unreal Tournament GOTY/99 does not (seem to). And I doubt someone
is going to fix commercial games. Though being a static binary,
its use of shared libraries that do the sound device open makes
aoss a possibility, if that helps. But it does not support ALSA
natively - and would make a point for CUSE.

Re: [ANNOUNCE] OSS Proxy using CUSE

[Tejun Heo]

Jan Engelhardt wrote:
> On Thursday 2008-08-28 22:01, Adrian Bunk wrote:
>> On Thu, Aug 28, 2008 at 09:05:53PM +0200, Tejun Heo wrote:
>>> Hello again,
>>>
>>> So, after all the fuss, here's the state-of-the-art standard-compliant
>>> cloud-computing web-3.0-beta web page for OSS emulation using CUSE.
>>>
>>>   http://userweb.kernel.org/~tj/ossp/
>>>
>>> It works pretty well here.  :-)
>> Sorry for being destructive, but 6 years after ALSA went into the
>> kernel we are slightly approaching the point where all applications 
>> support ALSA.
> 
> Unreal Tournament GOTY/99 does not (seem to). And I doubt someone
> is going to fix commercial games. Though being a static binary,
> its use of shared libraries that do the sound device open makes
> aoss a possibility, if that helps. But it does not support ALSA
> natively - and would make a point for CUSE.

The devel version of ossp (not out yet, waiting for CUSE and mmap
support merge) can do all the quakes (even the dreaded quake1 which
even ALSA OSS emulation or native OSS can't do because of strict
sample/freq requirement which modern devices don't support anymore)
and skype-static-oss are working fine.  The latency is still a tad bit
high due to PA interaction but everything is mostly in place.  I'm
fairly sure UT would work too.  Do you know where I can get a demo of
it?

Thanks.

-- 
tejun

Re: [ANNOUNCE] OSS Proxy using CUSE

[Jan Engelhardt]

On Friday 2008-11-28 03:23, Tejun Heo wrote:
>Jan Engelhardt wrote:
>> On Thursday 2008-08-28 22:01, Adrian Bunk wrote:
>>> On Thu, Aug 28, 2008 at 09:05:53PM +0200, Tejun Heo wrote:
>>>> Hello again,
>>>>
>>>> So, after all the fuss, here's the state-of-the-art standard-compliant
>>>> cloud-computing web-3.0-beta web page for OSS emulation using CUSE.
>>>>
>>>>   http://userweb.kernel.org/~tj/ossp/
>>>>
>>>> It works pretty well here.  :-)
>>> Sorry for being destructive, but 6 years after ALSA went into the
>>> kernel we are slightly approaching the point where all applications 
>>> support ALSA.
>> 
>> Unreal Tournament GOTY/99 does not (seem to). And I doubt someone
>> is going to fix commercial games. Though being a static binary,
>> its use of shared libraries that do the sound device open makes
>> aoss a possibility, if that helps. But it does not support ALSA
>> natively - and would make a point for CUSE.
>
>The devel version of ossp (not out yet, waiting for CUSE and mmap
>support merge) can do all the quakes (even the dreaded quake1 which
>even ALSA OSS emulation or native OSS can't do because of strict
>sample/freq requirement which modern devices don't support anymore)

Quake won't be a problem because its source was released.

>and skype-static-oss are working fine.

Skype should burn in hell...

>The latency is still a tad bit
>high due to PA interaction but everything is mostly in place.  I'm
>fairly sure UT would work too.  Do you know where I can get a demo of
>it?

It has become really difficult to obtain these nowadays, but there it is:

http://download.beyondunreal.com/get.php/2/official/ut/utdemo-linux-x86-348.tar.gz


(BTW, Firefox3 screws up on loading
http://download.beyondunreal.com/fileworks.php/official/ut/utdemo-linux-x86-348.tar.gz
w3m works fine and was used to obtain the nested link above.)

Re: [ANNOUNCE] OSS Proxy using CUSE

[Tejun Heo]

Jan Engelhardt wrote:
>> The devel version of ossp (not out yet, waiting for CUSE and mmap
>> support merge) can do all the quakes (even the dreaded quake1 which
>> even ALSA OSS emulation or native OSS can't do because of strict
>> sample/freq requirement which modern devices don't support anymore)
> 
> Quake won't be a problem because its source was released.

Well, it's still nice to just download the stock demo and being able
to run it.  Has q2 been open sourced too?

>> and skype-static-oss are working fine.
> 
> Skype should burn in hell...

Heh... it's the only working IP phone solution over here.

>> The latency is still a tad bit
>> high due to PA interaction but everything is mostly in place.  I'm
>> fairly sure UT would work too.  Do you know where I can get a demo of
>> it?
> 
> It has become really difficult to obtain these nowadays, but there it is:
> 
> http://download.beyondunreal.com/get.php/2/official/ut/utdemo-linux-x86-348.tar.gz
> 
> 
> (BTW, Firefox3 screws up on loading
> http://download.beyondunreal.com/fileworks.php/official/ut/utdemo-linux-x86-348.tar.gz
> w3m works fine and was used to obtain the nested link above.)

Thanks.  Will try that.

-- 
tejun

Re: [ANNOUNCE] OSS Proxy using CUSE

[Jan Engelhardt]

On Friday 2008-11-28 13:02, Tejun Heo wrote:
>Jan Engelhardt wrote:
>>> The devel version of ossp (not out yet, waiting for CUSE and mmap
>>> support merge) can do all the quakes (even the dreaded quake1 which
>>> even ALSA OSS emulation or native OSS can't do because of strict
>>> sample/freq requirement which modern devices don't support anymore)
>> 
>> Quake won't be a problem because its source was released.
>
>Well, it's still nice to just download the stock demo and being able
>to run it.  Has q2 been open sourced too?

Yes and Q3 too.

Re: [ANNOUNCE] OSS Proxy using CUSE

[Takashi Iwai]

At Thu, 28 Aug 2008 21:05:53 +0200,
Tejun Heo wrote:
> 
> Hello again,
> 
> So, after all the fuss, here's the state-of-the-art standard-compliant
> cloud-computing web-3.0-beta web page for OSS emulation using CUSE.
> 
>   http://userweb.kernel.org/~tj/ossp/
> 
> It works pretty well here.  :-)

Thanks for info.  Just a quick glance, CUSE looks like a good
abstraction for this kind of things.

I've been thinking that the tunneling to an OSS-emulation daemon would
be the best way, too, and I actually made a similar hack (not based on
FUSE but own kernel module).

It was presented in SUSE Labs conference a few years ago.  And the
reaction by audience at that time was what Adrian showed -- why do we
need such a complexity at all?  Well, as long as we have OSS API and
its applications, we should keep supporting them in a good form.

Anyway, my implementation at that time was too hackish and I gave up
soon.  If it can be implemented in a generic framework like CUSE,
it's a good chance to merge to the upstream.

One thing I couldn't find in your code is the mmap support.
The mmap support is crucial for some apps, typically used for games.
Am I missing something?


thanks,

Takashi

Re: [ANNOUNCE] OSS Proxy using CUSE

[Tejun Heo]

Hello,

Takashi Iwai wrote:
> Thanks for info.  Just a quick glance, CUSE looks like a good
> abstraction for this kind of things.
> 
> I've been thinking that the tunneling to an OSS-emulation daemon would
> be the best way, too, and I actually made a similar hack (not based on
> FUSE but own kernel module).
> 
> It was presented in SUSE Labs conference a few years ago.  And the
> reaction by audience at that time was what Adrian showed -- why do we
> need such a complexity at all?  Well, as long as we have OSS API and
> its applications, we should keep supporting them in a good form.
> 
> Anyway, my implementation at that time was too hackish and I gave up
> soon.  If it can be implemented in a generic framework like CUSE,
> it's a good chance to merge to the upstream.
> 
> One thing I couldn't find in your code is the mmap support.
> The mmap support is crucial for some apps, typically used for games.
> Am I missing something?

mmap is essential for some apps?  Aiee... I was hoping to skip that one
after reading strong discouragement against it in the OSS programming
manual from 4front.

Adding it shouldn't be too difficult.  I'll give it a shot after other
stuff settles down.

Thanks.

-- 
tejun

[ANNOUNCE] OSS Proxy 1.2 using CUSE

[Tejun Heo]

Hello,

OSSP 1.2 available.  It now can do mmap for both playback and
recording.  All my quakes and dooms run and sound fine.  :-)

  http://userweb.kernel.org/~tj/ossp/

Thanks.

-- 
tejun

Re: [ANNOUNCE] OSS Proxy 1.2 using CUSE

[Miklos Szeredi]

On Tue, 14 Apr 2009, Tejun Heo wrote:
> OSSP 1.2 available.  It now can do mmap for both playback and
> recording.  All my quakes and dooms run and sound fine.  :-)
> 
>   http://userweb.kernel.org/~tj/ossp/

Xmms with the OSS output plugin doesn't really work.  It plays like 10
times too fast and the output is not really recognizable.

This is the debug output of osspd:

osspd: OSS Proxy v1.2 (C) 2008-2009 by Tejun Heo <teheo@suse.de>
osspd: Creating dsp (14:3), adsp (14:12), mixer (14:0)
osspd DBG0: CREATE mixer(12799)
osspd DBG0: S[1/16744] CREATE slave=16745 /store/git/ossp/ossp-padsp
osspd DBG0: S[1/16744]   client=16744 cmd=7:8 notify=9:10
ossp-padsp[mszeredi:16745] DBG0: requested frag_size (4096) is smaller than mini
mum (4412)
ossp-padsp[mszeredi:16745] DBG0: CREATE PLAY s16le 2ch 44100Hz fsz=4412:25
ossp-padsp[mszeredi:16745] DBG0:   tlen=131072:743 max=139896:793 pre=8192:46
ossp-padsp[mszeredi:16745] DBG0:   u_sd=0 u_fsz=4096:23 u_maxf=32
osspd DBG0: S[1/16744] volume set=-1/-1:-1/-1 get=63/63:0/0
ossp-padsp[mszeredi:16745] DBG0: PLAY stream underrun
ossp-padsp[mszeredi:16745] DBG0: PLAY stream underrun
ossp-padsp[mszeredi:16745] DBG0: PLAY stream underrun
ossp-padsp[mszeredi:16745] DBG0: PLAY stream underrun
ossp-padsp[mszeredi:16745] DBG0: PLAY stream underrun
ossp-padsp[mszeredi:16745] DBG0: PLAY stream underrun
[...message repeated zillion times]

I guess this has something to do with the too small frag size, but
couldn't figure out how all this works in prepare_streams() and
padsp_write().

Thanks,
Miklos

Re: [ANNOUNCE] OSS Proxy 1.2 using CUSE

[Tejun Heo]

Hello, Miklos.

Miklos Szeredi wrote:
> Xmms with the OSS output plugin doesn't really work.  It plays like 10
> times too fast and the output is not really recognizable.

Hmm...

> This is the debug output of osspd:
> 
> osspd: OSS Proxy v1.2 (C) 2008-2009 by Tejun Heo <teheo@suse.de>
> osspd: Creating dsp (14:3), adsp (14:12), mixer (14:0)
> osspd DBG0: CREATE mixer(12799)
> osspd DBG0: S[1/16744] CREATE slave=16745 /store/git/ossp/ossp-padsp
> osspd DBG0: S[1/16744]   client=16744 cmd=7:8 notify=9:10
> ossp-padsp[mszeredi:16745] DBG0: requested frag_size (4096) is smaller than mini
> mum (4412)
> ossp-padsp[mszeredi:16745] DBG0: CREATE PLAY s16le 2ch 44100Hz fsz=4412:25
> ossp-padsp[mszeredi:16745] DBG0:   tlen=131072:743 max=139896:793 pre=8192:46
> ossp-padsp[mszeredi:16745] DBG0:   u_sd=0 u_fsz=4096:23 u_maxf=32
> osspd DBG0: S[1/16744] volume set=-1/-1:-1/-1 get=63/63:0/0
> ossp-padsp[mszeredi:16745] DBG0: PLAY stream underrun
> ossp-padsp[mszeredi:16745] DBG0: PLAY stream underrun
> ossp-padsp[mszeredi:16745] DBG0: PLAY stream underrun
> ossp-padsp[mszeredi:16745] DBG0: PLAY stream underrun
> ossp-padsp[mszeredi:16745] DBG0: PLAY stream underrun
> ossp-padsp[mszeredi:16745] DBG0: PLAY stream underrun

Hmmm..

> [...message repeated zillion times]
> 
> I guess this has something to do with the too small frag size, but
> couldn't figure out how all this works in prepare_streams() and
> padsp_write().

Yeah, it's a bit convoluted.  I'll try xmms.

Thanks.

-- 
tejun

Re: [ANNOUNCE] OSS Proxy 1.2 using CUSE

[Tejun Heo]

Hello, Mikos.

Tejun Heo wrote:
> Hello, Miklos.
> 
> Miklos Szeredi wrote:
>> Xmms with the OSS output plugin doesn't really work.  It plays like 10
>> times too fast and the output is not really recognizable.
> 
> Hmm...
> 
>> This is the debug output of osspd:
>>
>> osspd: OSS Proxy v1.2 (C) 2008-2009 by Tejun Heo <teheo@suse.de>
>> osspd: Creating dsp (14:3), adsp (14:12), mixer (14:0)
>> osspd DBG0: CREATE mixer(12799)
>> osspd DBG0: S[1/16744] CREATE slave=16745 /store/git/ossp/ossp-padsp
>> osspd DBG0: S[1/16744]   client=16744 cmd=7:8 notify=9:10
>> ossp-padsp[mszeredi:16745] DBG0: requested frag_size (4096) is smaller than mini
>> mum (4412)
>> ossp-padsp[mszeredi:16745] DBG0: CREATE PLAY s16le 2ch 44100Hz fsz=4412:25
>> ossp-padsp[mszeredi:16745] DBG0:   tlen=131072:743 max=139896:793 pre=8192:46
>> ossp-padsp[mszeredi:16745] DBG0:   u_sd=0 u_fsz=4096:23 u_maxf=32
>> osspd DBG0: S[1/16744] volume set=-1/-1:-1/-1 get=63/63:0/0
>> ossp-padsp[mszeredi:16745] DBG0: PLAY stream underrun
>> ossp-padsp[mszeredi:16745] DBG0: PLAY stream underrun
>> ossp-padsp[mszeredi:16745] DBG0: PLAY stream underrun
>> ossp-padsp[mszeredi:16745] DBG0: PLAY stream underrun
>> ossp-padsp[mszeredi:16745] DBG0: PLAY stream underrun
>> ossp-padsp[mszeredi:16745] DBG0: PLAY stream underrun

Finally tried xmms.  It looks like a bug in pulseaudio.  pulseaudio is
throwing away data buffer after playing only fraction of it.
Interestingly, this can be avoided by having pavucontrol or other play
stream running.  Can you please verify that the problem goes away if
you have pavucontrol running?  There's also another problem with xmms.
The current version of ossp blocks mixer commands till the r/w
commands are complete and this makes xmms's UI stutter a bit.  I
modified osspd to lazy execute mixer commands while responding
immediately to the requester.  I'm testing it now and with pavucontrol
open, xmms works quite nicely.

Thanks.

-- 
tejun

Re: [ANNOUNCE] OSS Proxy 1.2 using CUSE

[Tejun Heo]

Tejun Heo wrote:
> I'm testing it now and with pavucontrol open, xmms works quite
> nicely.

Okay pushed v1.3 update to the git tree.

  git://git.kernel.org/pub/scm/linux/kernel/git/tj/ossp.git master
  http://git.kernel.org/?p=linux/kernel/git/tj/ossp.git;a=summary

Thanks.

-- 
tejun

Re: [ANNOUNCE] OSS Proxy 1.2 using CUSE

[Miklos Szeredi]

>From the README:

| ALSA contains OSS emulation but sadly the emulation is behind
| multiplexing layer (which is in userland) which means that if your
| sound card doesn't support multiple audio streams, only either one of
| ALSA or OSS interface would be usable at any given moment.

This seems to imply (and I was hoping very much) that this won't be a
limitation of a CUSE based OSS Proxy.  But at the moment I'm finding
that while ossp is doing some playback other ALSA apps cannot start
playback and vice versa.

In fact if something else is playing though ALSA and I start a
playback through ossp, then ossp will print some errors, return EIO
and get into a bad state, that it recoveres from only by starting the
playback twice more (after stopping the other playback through ALSA).

ossp-padsp[mszeredi:24123]  ERR: pa_stream_write() failed (Connection terminated)
osspd  ERR: failed to read_fill 16 bytes from fd 7 (Connection reset by peer)
osspd WARN: S[1/24122] communication with slave failed (can't read reply: Connection reset by peer)
E: socket-client.c: socket(): Address family not supported by protocol
E: context.c: waitpid(): No child processes
ossp-padsp[mszeredi:24130]  ERR: failed to connect context, state=5 (Bad state)

Thanks,
Miklos

Re: [ANNOUNCE] OSS Proxy 1.2 using CUSE

[Takashi Iwai]

At Tue, 28 Apr 2009 18:01:08 +0200,
Miklos Szeredi wrote:
> 
> >From the README:
> 
> | ALSA contains OSS emulation but sadly the emulation is behind
> | multiplexing layer (which is in userland) which means that if your
> | sound card doesn't support multiple audio streams, only either one of
> | ALSA or OSS interface would be usable at any given moment.
> 
> This seems to imply (and I was hoping very much) that this won't be a
> limitation of a CUSE based OSS Proxy.  But at the moment I'm finding
> that while ossp is doing some playback other ALSA apps cannot start
> playback and vice versa.
> 
> In fact if something else is playing though ALSA and I start a
> playback through ossp, then ossp will print some errors, return EIO
> and get into a bad state, that it recoveres from only by starting the
> playback twice more (after stopping the other playback through ALSA).

Are you using pulse plugin for ALSA, too?
Looks like ossp tries the pulseaudio.  If you are using the native
ALSA, of course it'll block the access by PA...


Takashi

> ossp-padsp[mszeredi:24123]  ERR: pa_stream_write() failed (Connection terminated)
> osspd  ERR: failed to read_fill 16 bytes from fd 7 (Connection reset by peer)
> osspd WARN: S[1/24122] communication with slave failed (can't read reply: Connection reset by peer)
> E: socket-client.c: socket(): Address family not supported by protocol
> E: context.c: waitpid(): No child processes
> ossp-padsp[mszeredi:24130]  ERR: failed to connect context, state=5 (Bad state)
> 
> Thanks,
> Miklos
> 

Re: [ANNOUNCE] OSS Proxy 1.2 using CUSE

[Miklos Szeredi]

On Tue, 28 Apr 2009, Takashi Iwai wrote:
> > In fact if something else is playing though ALSA and I start a
> > playback through ossp, then ossp will print some errors, return EIO
> > and get into a bad state, that it recoveres from only by starting the
> > playback twice more (after stopping the other playback through ALSA).
> 
> Are you using pulse plugin for ALSA, too?

alsa-plugins-pulse package is installed.  How can I find out if ALSA
is actually using this plugin?

What is the disadvantage of non-native ALSA vs. native ALSA?

Thanks,
Miklos

Re: [ANNOUNCE] OSS Proxy 1.2 using CUSE

[Takashi Iwai]

At Tue, 28 Apr 2009 19:17:14 +0200,
Miklos Szeredi wrote:
> 
> On Tue, 28 Apr 2009, Takashi Iwai wrote:
> > > In fact if something else is playing though ALSA and I start a
> > > playback through ossp, then ossp will print some errors, return EIO
> > > and get into a bad state, that it recoveres from only by starting the
> > > playback twice more (after stopping the other playback through ALSA).
> > 
> > Are you using pulse plugin for ALSA, too?
> 
> alsa-plugins-pulse package is installed.  How can I find out if ALSA
> is actually using this plugin?

For example, if you start aplay with -v option, it'll show the plugins
to use.

> What is the disadvantage of non-native ALSA vs. native ALSA?

Well, the question is rather whether you need PA or not...


Takashi

Re: [ANNOUNCE] OSS Proxy 1.2 using CUSE

[Miklos Szeredi]

On Tue, 28 Apr 2009, Takashi Iwai wrote:
> At Tue, 28 Apr 2009 19:17:14 +0200,
> Miklos Szeredi wrote:
> > 
> > On Tue, 28 Apr 2009, Takashi Iwai wrote:
> > > Are you using pulse plugin for ALSA, too?
> > 
> > alsa-plugins-pulse package is installed.  How can I find out if ALSA
> > is actually using this plugin?
> 
> For example, if you start aplay with -v option, it'll show the plugins
> to use.

OK, it doesn't.  So I have to tweak some config files to make it use
this plugin...

...done.  Well, now things do work, but the sound quality is very
crappy when PA is mixing two or more streams together (loud cracking
that maybe sounds like integer overflow).

> > What is the disadvantage of non-native ALSA vs. native ALSA?
> 
> Well, the question is rather whether you need PA or not...

Yes, OSSP needs it.  So the question (to Tejun) is why does OSSP use
libpulse API instead of libalsa API?

The former seems to be much more mature and easier to configure than
the latter.

Thanks,
Miklos

Re: [ANNOUNCE] OSS Proxy 1.2 using CUSE

[Takashi Iwai]

At Tue, 28 Apr 2009 22:12:18 +0200,
Miklos Szeredi wrote:
> 
> On Tue, 28 Apr 2009, Takashi Iwai wrote:
> > At Tue, 28 Apr 2009 19:17:14 +0200,
> > Miklos Szeredi wrote:
> > > 
> > > On Tue, 28 Apr 2009, Takashi Iwai wrote:
> > > > Are you using pulse plugin for ALSA, too?
> > > 
> > > alsa-plugins-pulse package is installed.  How can I find out if ALSA
> > > is actually using this plugin?
> > 
> > For example, if you start aplay with -v option, it'll show the plugins
> > to use.
> 
> OK, it doesn't.  So I have to tweak some config files to make it use
> this plugin...
> 
> ...done.  Well, now things do work, but the sound quality is very
> crappy when PA is mixing two or more streams together (loud cracking
> that maybe sounds like integer overflow).

Or because of older version of PA.  The one in SUSE Factory (or some
OBS repo), version 0.9.14 or newer, might improve it.


Takashi

Re: [ANNOUNCE] OSS Proxy 1.2 using CUSE

[Miklos Szeredi]

On Tue, 28 Apr 2009, Takashi Iwai wrote:
> At Tue, 28 Apr 2009 22:12:18 +0200,
> Miklos Szeredi wrote:
> > ...done.  Well, now things do work, but the sound quality is very
> > crappy when PA is mixing two or more streams together (loud cracking
> > that maybe sounds like integer overflow).
> 
> Or because of older version of PA.  The one in SUSE Factory (or some
> OBS repo), version 0.9.14 or newer, might improve it.

OK, 0.9.14 is much better than 0.9.12.  Thanks for the help.

Miklos

Re: [ANNOUNCE] OSS Proxy 1.2 using CUSE

[Tejun Heo]

Hello, Miklos.

Miklos Szeredi wrote:
>> For example, if you start aplay with -v option, it'll show the plugins
>> to use.
> 
> OK, it doesn't.  So I have to tweak some config files to make it use
> this plugin...
> 
> ...done.  Well, now things do work, but the sound quality is very
> crappy when PA is mixing two or more streams together (loud cracking
> that maybe sounds like integer overflow).

Which version are you using, it got better and then worse and then
better again IIRC.  Yeah, it's still in the process of maturing.

>>> What is the disadvantage of non-native ALSA vs. native ALSA?
>> Well, the question is rather whether you need PA or not...
> 
> Yes, OSSP needs it.  So the question (to Tejun) is why does OSSP use
> libpulse API instead of libalsa API?
> 
> The former seems to be much more mature and easier to configure than
> the latter.

On default installation of any recent major distros, PA is the default
and ALSA via PA is the default too, so the configuration doesn't
matter at all.  I think PA is the way to go (all other guys are
already there) && we're past the point of no return at this point &&
it's nicer to program to and has some features I wanted (per-pgrp
volume for example), so...

Thanks.

-- 
tejun

Re: [ANNOUNCE] OSS Proxy 1.2 using CUSE

[Miklos Szeredi]

On Wed, 29 Apr 2009, Tejun Heo wrote:
> On default installation of any recent major distros, PA is the default
> and ALSA via PA is the default too, so the configuration doesn't
> matter at all.  I think PA is the way to go (all other guys are
> already there) && we're past the point of no return at this point &&
> it's nicer to program to and has some features I wanted (per-pgrp
> volume for example), so...

If distros are committed to making PA the default, and ALSA through PA
doesn't have any major disadvatnages then it sounds like a perfect
solution to everything.

The fact that OpenSUSE-11.1 is not there yet just made me think this
problem is worse than it really is.

Thanks,
Miklos

Re: [ANNOUNCE] OSS Proxy 1.2 using CUSE

[Tejun Heo]

Miklos Szeredi wrote:
> If distros are committed to making PA the default, and ALSA through PA
> doesn't have any major disadvatnages then it sounds like a perfect
> solution to everything.
> 
> The fact that OpenSUSE-11.1 is not there yet just made me think this
> problem is worse than it really is.

SL111 is configured to use PA by default and works just fine (sans
bugs of course).  Even SL110 was fine from configuration POV although
there were more bugs.  I have no idea why ALSA via PA took explicit
configuration on your machine.

Thanks.

-- 
tejun