Re: Native NetBSD audio driver

[Eric Pouech]

Yorick Hardy a écrit :
> This patch adds the audio driver winenbsd using the native NetBSD
> audio system as an alternative to OSS. On the one hand
> this is useful to directly make use of the features of the NetBSD
> audio system instead of using emulation, on the other hand
> it is another driver to maintain and is quite close to the wineoss driver.
> If the driver is accepted, I think the NetBSD support for wineoss
> should remain for testing and for the main driver.

I really think we're starting to create a real mess for the audio 
drivers. It's always useful to have drivers access the HW at the lowest 
level, so we should support NetBSD.
However, if the iface is rather close to OSS, I'd rather suggest we try 
to integrate all the drivers with the same features into a single piece 
of driver
> diff -urN /home/yorick/software/wine/wine/dlls/Makefile.in ./dlls/Makefile.in
> --- /home/yorick/software/wine/wine/dlls/Makefile.in	Sat Feb 14 19:20:00 2004
> +++ ./dlls/Makefile.in	Sat Feb 21 23:43:35 2004
> @@ -1745,6 +1749,7 @@
>  winmm/winejack/winejack.drv$(DLLEXT): winmm/winejack
>  msacm/winemp3/winemp3.acm$(DLLEXT): msacm/winemp3
>  winmm/winenas/winenas.drv$(DLLEXT): winmm/winenas
> +winmm/winenas/winenbsd.drv$(DLLEXT): winmm/winenbsd

***
this should be winenbsd
A+

Native NetBSD audio driver

[Yorick Hardy]

Good catch, thanks. I will resubmit tonight.
> > diff -urN /home/yorick/software/wine/wine/dlls/Makefile.in
> > ./dlls/Makefile.in
> > --- /home/yorick/software/wine/wine/dlls/Makefile.in	Sat Feb 14 19:20:00
> > 2004
> > +++ ./dlls/Makefile.in	Sat Feb 21 23:43:35 2004
> > @@ -1745,6 +1749,7 @@
> >  winmm/winejack/winejack.drv$(DLLEXT): winmm/winejack
> >  msacm/winemp3/winemp3.acm$(DLLEXT): msacm/winemp3
> >  winmm/winenas/winenas.drv$(DLLEXT): winmm/winenas
> > +winmm/winenas/winenbsd.drv$(DLLEXT): winmm/winenbsd
>           ***
>
> this should be winenbsd
> A+

--------------------------------------------------------
This message was sent using MetroWEB's AirMail service.
http://www.metroweb.co.za/ - full access for only R59.
Free WebMail, Calendar, Anti-Virus, Anti-Spam, 10 emails
Phone Now!  086 11 11 440

Native NetBSD audio driver

[Yorick Hardy]

Thanks for the input.
Here is the patch again, with the bug specified below fixed.
I definitely think it would be useful to integrate at least the
winenbsd and wineoss drivers somehow. However, I think
a separate winenbsd driver will have to do in the mean time, and
provides a starting point to compare the drivers in case someone
else is also interested.

Changelog: Add the winenbsd audio driver using the native NetBSD audio system.

On Sun, Feb 22, 2004 at 06:15:47PM +0100, Eric Pouech wrote:
> I really think we're starting to create a real mess for the audio 
> drivers. It's always useful to have drivers access the HW at the lowest 
> level, so we should support NetBSD.
> However, if the iface is rather close to OSS, I'd rather suggest we try 
> to integrate all the drivers with the same features into a single piece 
> of driver
> > +++ ./dlls/Makefile.in	Sat Feb 21 23:43:35 2004
> > @@ -1745,6 +1749,7 @@
> > winmm/winejack/winejack.drv$(DLLEXT): winmm/winejack
> > msacm/winemp3/winemp3.acm$(DLLEXT): msacm/winemp3
> > winmm/winenas/winenas.drv$(DLLEXT): winmm/winenas
> > +winmm/winenas/winenbsd.drv$(DLLEXT): winmm/winenbsd
>          ***
>
> this should be winenbsd

Kind regards,

Native NetBSD audio driver

[Dimitrie O. Paun]

On Mon, 23 Feb 2004, Yorick Hardy wrote:
> a separate winenbsd driver will have to do in the mean time, and
> provides a starting point to compare the drivers in case someone
> else is also interested.

I think quite the opposite is true: having an almost identical
driver in the tree simply obscures the matter more. The two will
diverge in time, and the NetBSD one will slowly bitrot. Now that
the two are the closest it's the time to document the differences
and integrate them in the OSS driver.

Native NetBSD audio driver

[Joerg Mayer]

On Mon, Feb 23, 2004 at 06:50:33PM -0500, Dimitrie O. Paun wrote:
> I think quite the opposite is true: having an almost identical
> driver in the tree simply obscures the matter more. The two will
> diverge in time, and the NetBSD one will slowly bitrot. Now that
> the two are the closest it's the time to document the differences
> and integrate them in the OSS driver.

I think that the future of Linux sound will be more with alsa than
with oss. AFAIK, alsa does not exist with xxxBSD, so in my opinion,
using and supporting the respective interfaces instead of oss makes
more sense.

Ciao
   Jörg

Native NetBSD audio driver

[Robert Reif]

I  think it might be worthwhile considering restructuring the audio
drivers into hardware independent wave, direct sound, midi
and  mixer sections and a hardware dependent  low level
implementation for oss, alsa, ...

The basic structure of all the drivers is similar enough to abstracted
out the hardware independent portions.

Joerg Mayer wrote:
> On Mon, Feb 23, 2004 at 06:50:33PM -0500, Dimitrie O. Paun wrote:
> > I think quite the opposite is true: having an almost identical
> > driver in the tree simply obscures the matter more. The two will
> > diverge in time, and the NetBSD one will slowly bitrot. Now that
> > the two are the closest it's the time to document the differences
> > and integrate them in the OSS driver.
>
> I think that the future of Linux sound will be more with alsa than
> with oss. AFAIK, alsa does not exist with xxxBSD, so in my opinion,
> using and supporting the respective interfaces instead of oss makes
> more sense.
>
> Ciao
>    Jörg
>
> --
> Joerg Mayer                                           
> We are stuck with technology when what we really want is just stuff that
> works. Some say that should read Microsoft instead of technology.

Native NetBSD audio driver

[Alexandre Julliard]

Robert Reif  writes:
> I  think it might be worthwhile considering restructuring the audio
> drivers into hardware independent wave, direct sound, midi
> and  mixer sections and a hardware dependent  low level
> implementation for oss, alsa, ...

Yes we should definitely do something like that. This sound driver
business is becoming a huge mess.

Native NetBSD audio driver

[James Gregory]

On Thu, 2004-02-26 at 08:59, Alexandre Julliard wrote:
> Robert Reif  writes:
> > I  think it might be worthwhile considering restructuring the audio
> > drivers into hardware independent wave, direct sound, midi
> > and  mixer sections and a hardware dependent  low level
> > implementation for oss, alsa, ...
>
> Yes we should definitely do something like that. This sound driver
> business is becoming a huge mess.

Is there a reason not to use something like libao here?

http://www.xiph.org/ao/

It lists NetBSD amongst the systems it supports. I suspect this will
only solve part of the problem, since it appears to only do PCM audio
output, but this has got to be a problem that has been solved before.

How complicated is the audio code? Would it be difficult for me to add a
libao driver?

James.

Native NetBSD audio driver

[Eric Pouech]

James Gregory a écrit :
> On Thu, 2004-02-26 at 08:59, Alexandre Julliard wrote:
> > Robert Reif  writes:
> > > I  think it might be worthwhile considering restructuring the audio
> > > drivers into hardware independent wave, direct sound, midi
> > > and  mixer sections and a hardware dependent  low level
> > > implementation for oss, alsa, ...
> >
> > Yes we should definitely do something like that. This sound driver
> > business is becoming a huge mess.
>
> Is there a reason not to use something like libao here?
> http://www.xiph.org/ao/
>
> It lists NetBSD amongst the systems it supports. I suspect this will
> only solve part of the problem, since it appears to only do PCM audio
> output, but this has got to be a problem that has been solved before.
>
> How complicated is the audio code? Would it be difficult for me to add a
> libao driver?

the issue here is that libao uses some thread related code to handle the 
asynchronous push of the audio stream. This could lead to some bad 
behavior in wine, and even portability issues as this is not abstracted 
well enough. And I didn't check the license

A+