Hi,
I'm starting to work on a native ALSA driver for wine. Since I remember that Marcus was working (or was planning to work) an that one too, I would like to know if there is already something to work on or to contribute to, or if I need to start from scratch.
If there is nothing already written, I would like to discuss what kind of approach we should use with ALSA programming, since FWIK there should be two way to use it: we can use the ALSA devices directly, just like it has been done with OSS, or we can use the alsalib to avoid all direct references to the kernel devices and ioctl, but this solution will add a dependency on the alsalib library itself to wine. Of course, we could add a configure option/check to allow its use at compilation time, but...
BTW, Alsalib is LGPL, so the license shouldn't be a problem.
bye,
/pietrobo
On Fri, Apr 19, 2002 at 05:57:07PM +0200, Marco Pietrobono wrote:
Hi,
I'm starting to work on a native ALSA driver for wine. Since I remember that Marcus was working (or was planning to work) an that one too, I would like to know if there is already something to work on or to contribute to, or if I need to start from scratch.
I was not planning to work on it as of this time.
Ciao, Marcus
Hi,
Eric has written one which is almost complete, I am in the midst of debugging it and finising it off.
Contact me directly if you like.
David
On 19 Apr 2002 17:57:07 +0200, Marco Pietrobono wrote:
| Hi, | | I'm starting to work on a native ALSA driver for wine. Since I | remember that Marcus was working (or was planning to work) an that one | too, I would like to know if there is already something to work on or to | contribute to, or if I need to start from scratch. | | If there is nothing already written, I would like to discuss what kind | of approach we should use with ALSA programming, since FWIK there should | be two way to use it: we can use the ALSA devices directly, just like it | has been done with OSS, or we can use the alsalib to avoid all direct | references to the kernel devices and ioctl, but this solution will add a | dependency on the alsalib library itself to wine. Of course, we could | add a configure option/check to allow its use at compilation time, | but... | | BTW, Alsalib is LGPL, so the license shouldn't be a problem. | | bye, | | /pietrobo | | | -- | Stud. Marco Pietrobono | Murphy's Law: if something could | v. del Calice, 39 - 00178 ROMA | go wrong, it does. | Tel. +39.06.7186329 339.7410893 | Legge di Murphy: se qualcosa può | http://www.pietrobo.com | andar male, lo farà. | ------------------------------------------------------------------------ | Strange game. | The only winning move | is not to play. | What about a nice play of chess ? |
On 19 Apr 2002, Marco Pietrobono wrote:
I'm starting to work on a native ALSA driver for wine. Since I remember that Marcus was working (or was planning to work) an that one too, I would like to know if there is already something to work on or to contribute to, or if I need to start from scratch.
You must be mistaken, Eric Pouech was working on the ALSA driver. This driver is also pretty much complete, just bugfixes remain. Unfortunately, it's currently in the cold slimy clutches (from the LGPL-Wine perspective) of TransGaming staff, who might not want to part with it without getting some of that glorious LGPL code in Wine relicensed in exchange...
On April 19, 2002 12:45 pm, Ove Kaaven wrote:
it's currently in the cold slimy clutches (from the LGPL-Wine perspective)
as if it's not from the X11-Wine perspective...
Ove Kaaven wrote:
On 19 Apr 2002, Marco Pietrobono wrote:
I'm starting to work on a native ALSA driver for wine. Since I remember that Marcus was working (or was planning to work) an that one too, I would like to know if there is already something to work on or to contribute to, or if I need to start from scratch.
You must be mistaken, Eric Pouech was working on the ALSA driver. This driver is also pretty much complete, just bugfixes remain. Unfortunately, it's currently in the cold slimy clutches (from the LGPL-Wine perspective) of TransGaming staff, who might not want to part with it without getting some of that glorious LGPL code in Wine relicensed in exchange...
Actually, we have no official claim over the ALSA driver - we offered to sponsor Eric Poech's development, but he asked that we put it into another sponsorship instead. I am going to try to get the details of our proposals to trade / sponsor some code up next week. We have this DIB engine we've been working on for a bit, for example....
It is true though that TransGaming's David Hammerton 'has his clutches' on the code - he's been working on it with Eric in his spare time. That said, I just checked and while his hands are kind of cold, they didn't appear to be at all slimy. David said that he might try to check it into the ReWind tree this weekend.
-Gav
On Fri, 19 Apr 2002, Gavriel State wrote:
Ove Kaaven wrote:
On 19 Apr 2002, Marco Pietrobono wrote:
I'm starting to work on a native ALSA driver for wine. Since I remember that Marcus was working (or was planning to work) an that one too, I would like to know if there is already something to work on or to contribute to, or if I need to start from scratch.
You must be mistaken, Eric Pouech was working on the ALSA driver. This driver is also pretty much complete, just bugfixes remain. Unfortunately, it's currently in the cold slimy clutches (from the LGPL-Wine perspective) of TransGaming staff, who might not want to part with it without getting some of that glorious LGPL code in Wine relicensed in exchange...
Actually, we have no official claim over the ALSA driver - we offered to sponsor Eric Poech's development, but he asked that we put it into another sponsorship instead.
Hmm. I guess some of my attempts at humor failed here... I never said that Eric had given us the code or that he couldn't submit it to wine if he wanted to, only that someone at transgaming was trying to finish it, so my message isn't strictly untrue, just very badly presented... I expected Eric to explain the real situation himself, but I suppose I can try to not add to the confusion in the future...
It is true though that TransGaming's David Hammerton 'has his clutches' on the code - he's been working on it with Eric in his spare time. That said, I just checked and while his hands are kind of cold, they didn't appear to be at all slimy.
Not even after lunch?
David said that he might try to check it into the ReWind tree this weekend.
OK.
Marco Pietrobono a écrit :
Hi,
I'm starting to work on a native ALSA driver for wine. Since I remember that Marcus was working (or was planning to work) an that one too, I would like to know if there is already something to work on or to contribute to, or if I need to start from scratch.
If there is nothing already written, I would like to discuss what kind of approach we should use with ALSA programming, since FWIK there should be two way to use it: we can use the ALSA devices directly, just like it has been done with OSS, or we can use the alsalib to avoid all direct references to the kernel devices and ioctl, but this solution will add a dependency on the alsalib library itself to wine. Of course, we could add a configure option/check to allow its use at compilation time, but...
after Gav and Ove clarified the license details, lets go back to the technical bits this driver is against ALSA 0.5 interface. It will provide the bare bone wave part, but not yet the mixer part nor the MIDI. Moreover, it should also support the mmap interface (this was part of the code that needed to be checked and revisited, and David should be looking into this)
basically, this would allow to turn on mmap (which greatly enhances the dsound playback quality) on all soundcards (some OSS emulations for ALSA don't allow a correct mmap on the OSS mmap interface, so directly using the ALSA mmap interface should take of it)
work will still be done on the installation stuff (basically, the registry must be written with either ALSA or OSS driver, depending on the installed interface on Linux)
then, an ALSA final should be written. As the ALSA interface has greatly evolved between 0.5 and 0.9, the ongoing ALSA driver will need to be rewritten for ALSA 1.0 (aka final). Until Linux 2.6 is out, there will be no need for ALSA 1.0, as most of the current distros ship with either OSS or ALSA 0.5.
A+
then, an ALSA final should be written. As the ALSA interface has greatly evolved between 0.5 and 0.9, the ongoing ALSA driver will need to be rewritten for ALSA 1.0 (aka final). Until Linux 2.6 is out, there will be no need for ALSA 1.0, as most of the current distros ship with either OSS or ALSA 0.5.
Sigh, Suse 8.0 just moved fom 0.5 to 0.9 - the Alsa developers regard 0.9 as more stable and having less bugs than 0.5. Why spend all that time on an obsolete driver? OK, that is mostly the disappointment speaking that I still won't be able to run wine with Alsa.
Ciao Jörg -- Joerg Mayer jmayer@loplof.de I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
Sigh, Suse 8.0 just moved fom 0.5 to 0.9 - the Alsa developers regard 0.9 as more stable and having less bugs than 0.5. Why spend all that time on an obsolete driver? OK, that is mostly the disappointment speaking that I still won't be able to run wine with Alsa.
the point is not whether 0.5 is technically better than 0.9 (or the other way around). The point is on the current installed base of ALSA drivers in the field, how many are 0.5 and how many are 0.9. Mandrake and Suse (at least) have been shipping 0.5 for more than one year, whereas 0.9 is brand new. It just means that 0.9 installed base is almost 0 (in percentage). So, spending time right now on 0.9 is not the top priority (at least for me). OTOH, since the OSS emulation in ALSA 0.5 is broken, the point is whether we fix it (using a pure ALSA 0.5 driver in Wine), or let users live with that (TG has disabled the HAL support in dsound just because of that and it's a PITA)
A+
Eric Pouech wrote:
the point is not whether 0.5 is technically better than 0.9 (or the other way around). The point is on the current installed base of ALSA drivers in the field, how many are 0.5 and how many are 0.9. Mandrake and Suse (at least) have been shipping 0.5 for more than one year, whereas 0.9 is brand new.
Perhaps not quite brand new, at least in "computer years" ;) In any case, I think that it is not unreasonable to expect someone wanting to run wine with sound to install 0.9. Relative newbies might get a bit of a shock at having to recompile their kernels to get ALSA. But I think many users, well at least me, would be rather disappointed at being expected to run 0.5 (assuming that would be required).
...just my opinion though.
But I think many users, well at least me, would be rather disappointed at being expected to run 0.5 (assuming that would be required).
I don't object having a 0.9 driver at all. But I consider today having a 0.5 is more important than a 0.9 (even if it's for a short (1 year ?) period of time)
A+
On Sat, Apr 20, 2002 at 09:40:31PM +0200, Eric Pouech wrote:
OK, that is mostly the disappointment speaking that I still won't be able to run wine with Alsa.
The point is on the current installed base of ALSA drivers
...
It just means that 0.9 installed base is almost 0 (in percentage).
With Suse 8.0 now shipping 0.9 and 0.9 being in the 2.5 development kernels, the userbase will start to grow fast.
So, spending time right now on 0.9 is not the top priority (at least for me).
That is your privilege as author :-)
So there is one more sound module for wine to be written, as the api has changed significantly between 0.5 and 0.9.
OTOH, since the OSS emulation in ALSA 0.5 is broken, the point is whether we fix it (using a pure ALSA 0.5 driver in Wine), or let users live with that (TG has disabled the HAL support
Yeah, I guess I automatically assumed that alsa 0.9 would be broken with respect to mmap too :-/
Ciao Jörg
-- Joerg Mayer jmayer@loplof.de I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, 20 Apr 2002, Eric Pouech wrote:
after Gav and Ove clarified the license details, lets go back to the technical bits this driver is against ALSA 0.5 interface. It will provide the bare bone wave part, but not yet the mixer part nor the MIDI. Moreover, it should also support the mmap interface (this was part of the code that needed to be checked and revisited, and David should be looking into this)
well, this seems a good start nevertheless.
I've just a little doubt. From what I've understood from the alsa-devel list, it seems that the ALSA 0.5 has been declared dead almost officially. They are not supporting it anymore, more over they are actively pushing the new 0.9 interface and library. IIRC, they want to get out a rc1 next week, or like.
BTW, It's been quite a while that I'm using ALSA 0.9, so I can try to port your code to it.
[snip]
then, an ALSA final should be written. As the ALSA interface has greatly evolved between 0.5 and 0.9, the ongoing ALSA driver will need to be rewritten for ALSA 1.0 (aka final). Until Linux 2.6 is out, there will be no need for ALSA 1.0, as most of the current distros ship with either OSS or ALSA 0.5.
I'm not so sure. It seems that the next versions of SuSE and Mandrake will contain ALSA 0.9, I don't know Red Hat plans on this one, as well as others' but I can check...
bye,
/pietrobo
- -- Stud. Marco Pietrobono | Murphy's Law: if something could v. del Calice, 39 - 00178 ROMA | go wrong, it does. Tel. +39.6.7186329 0339.7410893 | Legge di Murphy: se qualcosa può http://www.pietrobo.com | andar male, lo farà. - ------------------------------------------------------------------------ Strange game. The only winning move is not to play. What about a nice play of chess ?
Marco Pietrobono a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, 20 Apr 2002, Eric Pouech wrote:
after Gav and Ove clarified the license details, lets go back to the technical bits this driver is against ALSA 0.5 interface. It will provide the bare bone wave part, but not yet the mixer part nor the MIDI. Moreover, it should also support the mmap interface (this was part of the code that needed to be checked and revisited, and David should be looking into this)
well, this seems a good start nevertheless.
I've just a little doubt. From what I've understood from the alsa-devel list, it seems that the ALSA 0.5 has been declared dead almost officially. They are not supporting it anymore, more over they are actively pushing the new 0.9 interface and library. IIRC, they want to get out a rc1 next week, or like.
see my answer to Joërg about this.
BTW, It's been quite a while that I'm using ALSA 0.9, so I can try to port your code to it.
ok, but keep both 0.5 and 0.9 inside and also protect 0.9 code when only the 0.5 headers will be available.
A+
On Sat, Apr 20, 2002 at 09:42:12PM +0200, Eric Pouech wrote:
BTW, It's been quite a while that I'm using ALSA 0.9, so I can try to port your code to it.
ok, but keep both 0.5 and 0.9 inside and also protect 0.9 code when only the 0.5 headers will be available.
I don't think that this is the right way. IMHO, there should be one 0.5 and "current" alsa module for wine - they really have different apis. They have common features and an almost identical name, but that's it. It would be cleaner to copy you code completely into a separate alsa-0.9 ( or current or whatever) module and compile and install it separately.
Ciao Jörg -- Joerg Mayer jmayer@loplof.de I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
I don't think that this is the right way. IMHO, there should be one 0.5 and "current" alsa module for wine - they really have different apis. They have common features and an almost identical name, but that's it. It would be cleaner to copy you code completely into a separate alsa-0.9 ( or current or whatever) module and compile and install it separately.
yes an no. since we don't have a proper install (and detection) mechanism in wine, I was more leaning to having a single ALSA driver, that would compile into 0.5 or 0.9 (depending on the headers found on the system).
I agree that #ifdef:ing in the code is a bad idea.
A+
Eric Pouech eric.pouech@wanadoo.fr writes:
yes an no. since we don't have a proper install (and detection) mechanism in wine, I was more leaning to having a single ALSA driver, that would compile into 0.5 or 0.9 (depending on the headers found on the system).
That's the best solution assuming you can also compile it to support both 0.5 and 0.9 if you have all the necessary headers, and detect which version to use at run-time. If this is not possible we need two separate drivers, otherwise it won't be possible to build a binary package that works for everybody.
-
Alexandre Julliard -
David Hammerton -
Dimitrie O. Paun -
Duane Clark -
Eric Pouech -
Gavriel State -
Joerg Mayer -
Marco Pietrobono -
Marcus Meissner -
Ove Kaaven