Hi, This is the first of two patches that will fix some problems on soundcards using the i810 audio codec. The main probem with this soundcard is that it only supports a frequency of 48kHz in 16bit stereo mode. This first patch to dsound queries if the card supports 16bit and if so it uses it, else it uses 8bit. Further it also detects if the card supports stereo or not. The patch was inspired by one from transgaming to rewind but that patch did a bit the opposite (defaulting to 8bit ..). Roderick Colenbrander
I'm not sure deviating from the Microsoft behavior is correct. The default is 22khz 8 bit mono unless the hardware doesn't support it. Transgaming is correct. Another problem is that drivers support different formats in different modes. Because of software emulation in alsa, a driver may appear to support any format but then fail when you try to mmap it because then software conversions can't come into play. This is also a problem with OSS emulation in alsa on this type of hardware. Roderick Colenbrander wrote:
Hi,
This is the first of two patches that will fix some problems on soundcards using the i810 audio codec. The main probem with this soundcard is that it only supports a frequency of 48kHz in 16bit stereo mode.
This first patch to dsound queries if the card supports 16bit and if so it uses it, else it uses 8bit. Further it also detects if the card supports stereo or not. The patch was inspired by one from transgaming to rewind but that patch did a bit the opposite (defaulting to 8bit ..).
Roderick Colenbrander
------------------------------------------------------------------------ Name: dsound dsound Type: text/x-diff Encoding: 7bit
On Sat, 27 Mar 2004 14:36:31 -0500, Robert Reif wrote:
Another problem is that drivers support different formats in different modes. Because of software emulation in alsa, a driver may appear to support any format but then fail when you try to mmap it because then software conversions can't come into play.
I talked with one of the ALSA developers on IRC a day or two ago, and he appeared to think mmap would work regardless of what plugin chain was in use (resampling/conversion is implemented in alsa plugins). He said if it didn't work it was a bug. Anecdotal evidence seems to suggest this works now too. I was playing 22khz/8bit sample - the winamp demo file - on my i810 card and it was using MMAP access yet still able to play (for a few seconds before bailing with an assert in alsalib). IIRC in XP DirectSound primary buffers no longer correspond to the sound cards memory, they are just like any other and sent to the XP kernel mixer. Is it possible the same is now true of ALSA? thanks -mike
lør, 27.03.2004 kl. 20.40 skrev Mike Hearn:
On Sat, 27 Mar 2004 14:36:31 -0500, Robert Reif wrote:
Another problem is that drivers support different formats in different modes. Because of software emulation in alsa, a driver may appear to support any format but then fail when you try to mmap it because then software conversions can't come into play.
I talked with one of the ALSA developers on IRC a day or two ago, and he appeared to think mmap would work regardless of what plugin chain was in use (resampling/conversion is implemented in alsa plugins). He said if it didn't work it was a bug.
Only if you don't use kernel-level OSS emulation or the "hw" alsa device, I think. If you use alsa with the "default" or "plughw" devices, plugins will resample for you (and those plugins are able to "fake" mmaps). I'd think it's probably not a good idea to use ALSA plugins instead of Wine's own resampling functions, though.
IIRC in XP DirectSound primary buffers no longer correspond to the sound cards memory, they are just like any other and sent to the XP kernel mixer. Is it possible the same is now true of ALSA?
You can still go straight to the card's DMA buffer if you avoid plugins (either by setting a sample rate that matches the card's, or by using the "hw" device... and you probably need the latter anyway to find out which sample rates the card supports).
On Sun, 28 Mar 2004 05:31:01 +0200, Ove Kaaven wrote:
Only if you don't use kernel-level OSS emulation or the "hw" alsa device, I think. If you use alsa with the "default" or "plughw" devices, plugins will resample for you (and those plugins are able to "fake" mmaps). I'd think it's probably not a good idea to use ALSA plugins instead of Wine's own resampling functions, though.
OK. Francois seemed to think our own resampling would always be worse than alsalibs resampling - is there a reason we should use our own instead of alsalibs?
You can still go straight to the card's DMA buffer if you avoid plugins (either by setting a sample rate that matches the card's, or by using the "hw" device... and you probably need the latter anyway to find out which sample rates the card supports).
In that case I guess my patch was fixing the wrong thing, as I altered it to use the default device instead of hw (though it can be changed back in the registry). I'm still unhappy with the idea of direct access - if we circumvent the ALSA plugins system we'll never co-operate correctly with dmix/asym which is going to result in a ton of user unhappiness once these features are deployed (they are still a bit buggy but getting there fast). As even Windows these days has decided to drop direct access in favour of software emulation and mixing, why shouldn't we do the same? thanks -mike
Ok, will default to 8bit mono then. Shouldn't we add some options then to let the user select stereo and other things? Else dsound will about allways use this mode. My other patch fixed the problem with sample rate conversion (for alsa). If a wrong format was detected the winealsa driver would tell dsound to use a different format. Atleast this worked before Mike's patch. For the alsa oss emulation problem I have a workaround which I will port over and clean up. Basicly it opens the device for about all formats and if opening fails it means that a mode isn't supported. Roderick On Saturday 27 March 2004 20:36, Robert Reif wrote:
I'm not sure deviating from the Microsoft behavior is correct. The default is 22khz 8 bit mono unless the hardware doesn't support it. Transgaming is correct.
Another problem is that drivers support different formats in different modes. Because of software emulation in alsa, a driver may appear to support any format but then fail when you try to mmap it because then software conversions can't come into play. This is also a problem with OSS emulation in alsa on this type
of hardware.
Roderick Colenbrander wrote:
Hi,
This is the first of two patches that will fix some problems on soundcards using the i810 audio codec. The main probem with this soundcard is that it only supports a frequency of 48kHz in 16bit stereo mode.
This first patch to dsound queries if the card supports 16bit and if so it uses it, else it uses 8bit. Further it also detects if the card supports stereo or not. The patch was inspired by one from transgaming to rewind but that patch did a bit the opposite (defaulting to 8bit ..).
Roderick Colenbrander
------------------------------------------------------------------------ Name: dsound dsound Type: text/x-diff Encoding: 7bit
The application will generally set the format of the primary buffer to match the secondaries to ensure maximum performance. Unfortunately, since 2k and xp lie to the application and accept anything requested without regard to performance (actual hardware capabilities), some applications may not (or even be able to) do the optimal thing. This also lets manufacturers produce cheap dumb hardware and lets the software fix it up. We have win modems and win printers and now we are getting win sound cards. The OSS driver already tries all formats and returns it in the capabilities. In the case of alsa OSS emulation, what it reports and what it will actually mmap could be different. This is either a bug or design feature of alsa. You could try to mmap every format to see if it really supports that format but that's working around the driver. Direct sound shouldn't have to second guess what the driver is telling it. What alsa needs (and may already have) is a way to determine what is supported in hardware and what will be emulated and let the application figure out what is best but alsa wants to hide the implementation details. This is also the purpose of direct sound so they are both trying to do the same thing. The commercial OSS implementation also will do a software emulation of whatever you ask for but they also provide a way of disabling it if needed. Roderick Colenbrander wrote:
Ok, will default to 8bit mono then. Shouldn't we add some options then to let the user select stereo and other things? Else dsound will about allways use this mode.
My other patch fixed the problem with sample rate conversion (for alsa). If a wrong format was detected the winealsa driver would tell dsound to use a different format. Atleast this worked before Mike's patch.
For the alsa oss emulation problem I have a workaround which I will port over and clean up. Basicly it opens the device for about all formats and if opening fails it means that a mode isn't supported.
Roderick
On Saturday 27 March 2004 20:36, Robert Reif wrote:
I'm not sure deviating from the Microsoft behavior is correct. The default is 22khz 8 bit mono unless the hardware doesn't support it. Transgaming is correct.
Another problem is that drivers support different formats in different modes. Because of software emulation in alsa, a driver may appear to support any format but then fail when you try to mmap it because then software conversions can't come into play. This is also a problem with OSS emulation in alsa on this type
of hardware.
Roderick Colenbrander wrote:
Hi,
This is the first of two patches that will fix some problems on soundcards using the i810 audio codec. The main probem with this soundcard is that it only supports a frequency of 48kHz in 16bit stereo mode.
This first patch to dsound queries if the card supports 16bit and if so it uses it, else it uses 8bit. Further it also detects if the card supports stereo or not. The patch was inspired by one from transgaming to rewind but that patch did a bit the opposite (defaulting to 8bit ..).
Roderick Colenbrander
------------------------------------------------------------------------ Name: dsound dsound Type: text/x-diff Encoding: 7bit
I believe it makes sense for wine to keep the oss and alsa drivers as low level as possible for users that require performance over useability. The straight to hardware philosophy of direct sound should be honored when possible. This would be appropriate for games, voip or low latency music applications. If usability rather than performance (as in multiple applications) is important, then higher level drivers like jack or arts should be used. This gives the user the ability to choose which driver is most appropriate for their needs. Roderick Colenbrander wrote:
Hi,
This is the first of two patches that will fix some problems on soundcards using the i810 audio codec. The main probem with this soundcard is that it only supports a frequency of 48kHz in 16bit stereo mode.
This first patch to dsound queries if the card supports 16bit and if so it uses it, else it uses 8bit. Further it also detects if the card supports stereo or not. The patch was inspired by one from transgaming to rewind but that patch did a bit the opposite (defaulting to 8bit ..).
Roderick Colenbrander
------------------------------------------------------------------------ Name: dsound dsound Type: text/x-diff Encoding: 7bit
I believe it makes sense for wine to keep the oss and alsa drivers as low level as possible for users that require performance over useability. The straight to hardware philosophy of direct sound should be honored when possible. This would be appropriate for games, voip or low latency music applications.
ALSA is designed to avoid this sort of dichotomy. It does not matter to the app whether it opens "hw:0" or "plughw:0" or "plug:dmix:0" - the same code is used in every case. The fact that each of these virtual devices has quite different operating characteristics should be of interest to the user, but not to the code. There are places where this doesn't work. alsa-devel wants to hear about them, and plans to fix them.
If usability rather than performance (as in multiple applications) is important, then higher level drivers like jack or arts should be used.
JACK is not aimed at usability, but performance. It enforces timing constraints rather than leaving it to a bunch of hapless apps to mess it up. You cannot hope to use JACK within Wine without intermediate buffering, which actually makes using JACK somewhat pointless. I say somewhat only because it still permits device sharing, but at the cost of losing sample accurate synchronization. --p
The intermediate buffering is the issue. It's not a real big issue now with only a single buffer but it will be when wine supports hardware accelerated secondary buffers. You don't want 32 or 64 streams of data each going through multiple intermediate buffers for SRC, format, and volume changes. The point of direct sound is to provide the application programmer enough information about and control over the hardware to ensure optimal performance if desired. Hiding the hardware with layers of plugins is not the optimal approach. Even Microsoft learned that lesson the hard way. Alsa's approach of providing a consistent interface requardless of the amount of code or time or CPU resources used is great if that's what you want but they also need to provide a fast path to the hardware when that's desired. I know they are considering this but it is not a priority. Paul Davis wrote:
I believe it makes sense for wine to keep the oss and alsa drivers as low level as possible for users that require performance over useability. The straight to hardware philosophy of direct sound should be honored when possible. This would be appropriate for games, voip or low latency music applications.
ALSA is designed to avoid this sort of dichotomy. It does not matter to the app whether it opens "hw:0" or "plughw:0" or "plug:dmix:0" - the same code is used in every case. The fact that each of these virtual devices has quite different operating characteristics should be of interest to the user, but not to the code.
There are places where this doesn't work. alsa-devel wants to hear about them, and plans to fix them.
If usability rather than performance (as in multiple applications) is important, then higher level drivers like jack or arts should be used.
JACK is not aimed at usability, but performance. It enforces timing constraints rather than leaving it to a bunch of hapless apps to mess it up. You cannot hope to use JACK within Wine without intermediate buffering, which actually makes using JACK somewhat pointless. I say somewhat only because it still permits device sharing, but at the cost of losing sample accurate synchronization.
--p
The intermediate buffering is the issue. It's not a real big issue now with only a single buffer but it will be when wine supports hardware accelerated secondary buffers. You don't want 32 or 64 streams of data each going through multiple intermediate buffers for SRC, format, and volume changes. The point of direct sound is to provide the application programmer enough information about and control over the hardware to ensure optimal performance if desired. Hiding the hardware with layers of plugins is not the optimal approach. Even Microsoft learned that lesson the hard way. Alsa's approach of providing a consistent interface requardless of the amount of code or time or CPU resources used is great if that's what you want but they also need to provide a fast path to the hardware when that's desired. I know they are considering this but it is not a priority.
the extent to which you are right depends on the intended target. for pro-audio/music software, you're wrong. the APIs used by these programs do not and will not use the kinds of h/w features you mention. ASIO, in particular, does not model this kind of h/w, and there are very good reasons for that, "learned the hard way". Neither does GSIF or CoreAudio, the other two main "serious" audio APIs used by proaudio/music applications. we (i write this kind of stuff) don't use h/w features like this because the h/w is crap and there is never enough control over the algorithms. the reverbs found on audio interfaces aren't generally even close to usable for music production. and you can't use stuff like gain control because of the way the apps are structured (they are already implementing mixers with at least as much functionality as a high end mixing console). for games and some consumer software, yes, its probably true that using h/w facilities like this is desirable. there has been quite a bit of discussion about a new HAL for this stuff in ALSA over the last couple of months. some people are looking at specific cards for ideas about how to approach this. the model is still that the application code will be (more or less) identical, except perhaps for a few calls to toggle the choice of using h/w features if they exist. --p
On Mon, 29 Mar 2004 18:56:46 -0500, Robert Reif wrote:
If usability rather than performance (as in multiple applications) is important, then higher level drivers like jack or arts should be used.
Apart from JACK which is used in pro-audio situations, sound servers are probably going to be phased out on Linux within the next 12-24 months as people migrate to the 2.6 kernel with ALSA and the dmix/asym plugins. So, I still think the best way to solve this problem is simply to have a winecfg check box that says "Use hardware accelerated audio" which people who desire better performance can tick: they incur extra CPU overhead and the benefit is that they can use all their apps together. For many uses of Wine audio support is simply required for the bling!bling! sounds programs sometimes make. This is probably easier on the user than asking them to change their backend Wine audio driver. thanks -mike
OK, I'm convinced alsa is the way to go. How about using the already implemented HardwareAcceleration for setting the level of acceleration. Use Basic for a full plugin version, Standard for hw access and Full for real hardware acceleration when that becomes available. Emulation is already used for wave interface. When set to Basic, opening a primary or secondary buffer will succeed at the requested parameters regardless of hardware capabilities and all controls will be available. This would be for the typical non game user on low end hardware. Standard will open the hw device and return what format the hardware supports for the primary buffer and fail for secondary buffers if the format is not supported in hardware and only support controls available in hardware. This would be for the typical game user on game quality hardware Full will support the yet to be defined hardware acceleration interface Mike Hearn wrote:
On Mon, 29 Mar 2004 18:56:46 -0500, Robert Reif wrote:
If usability rather than performance (as in multiple applications) is important, then higher level drivers like jack or arts should be used.
Apart from JACK which is used in pro-audio situations, sound servers are probably going to be phased out on Linux within the next 12-24 months as people migrate to the 2.6 kernel with ALSA and the dmix/asym plugins.
So, I still think the best way to solve this problem is simply to have a winecfg check box that says "Use hardware accelerated audio" which people who desire better performance can tick: they incur extra CPU overhead and the benefit is that they can use all their apps together. For many uses of Wine audio support is simply required for the bling!bling! sounds programs sometimes make.
This is probably easier on the user than asking them to change their backend Wine audio driver.
thanks -mike
On Wed, 2004-03-31 at 00:39, Robert Reif wrote:
OK, I'm convinced alsa is the way to go. How about using the already implemented HardwareAcceleration for setting the level of acceleration. Use Basic for a full plugin version, Standard for hw access and Full for real hardware acceleration when that becomes available. Emulation is already used for wave interface.
That sounds great, as long as the default is basic (otherwise I can see a lot of confused users). Do you want to implement it? I've been pulled onto yet another direction and may not get back to i810/ALSA work for a while....
On Tue, Mar 30, 2004 at 03:19:19PM +0100, Mike Hearn wrote:
Apart from JACK which is used in pro-audio situations, sound servers are probably going to be phased out on Linux within the next 12-24 months as people migrate to the 2.6 kernel with ALSA and the dmix/asym plugins.
I don't think sound servers are going away, rather they will use snd_pcm_open to go through dmix or hardware mixer instead of opening (and potentially blocking) /dev/dsp. The traditional sound servers are useful because of the minimal amount of code required to do something like "play this wave file". The major remaining drawback is latency; click on button in app, hear sound 2 seconds later when scheduler finally chooses the sound server and it gets swapped back in. It is also rather stupid that GNOME and KDE utilize incompatible sound servers. aRts feature set is a superset of esd's feature set, so it seems sensible for both environments to make use of that one, or to add a sound server specification to the freedesktop.org standards. Maybe a better thing to do is rewrite arts/esd library interfaces to omit the daemons altogether. That way the daemons can go away, but the existing applications can be trivially migrated. -- Ryan Underwood, <nemesis(a)icequake.net>
On April 21, 2004 04:49 pm, Ryan Underwood wrote:
It is also rather stupid that GNOME and KDE utilize incompatible sound servers. aRts feature set is a superset of esd's feature set, so it seems sensible for both environments to make use of that one, or to add a sound server specification to the freedesktop.org standards.
Maybe a better thing to do is rewrite arts/esd library interfaces to omit the daemons altogether. That way the daemons can go away, but the existing applications can be trivially migrated.
I think it was Alan Cox who (first) made the observation that eventually the sound would need to be part of X11 (and hence the sound server part of the X server), otherwise you'll always have synchronisation issues between video and audio. Obviously arts is in the running for this, but the crucial part will be the protocol details, and no doubt all the other sound daemons will race to bolt themselves on to such a definition. If it's good enough for video cards ... BTW, I believe this was going to be one of the major talking points at some upcoming desktop symposium in Ottawa, but unfortunately I don't have any details handy (I heard it over a beer with the guy who was organising it, but I didn't take notes :-). Then again, which "free X project" would be first to develop this? <evil grin> Cheers, Geoff -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/
On Wed, Apr 21, 2004 at 04:59:55PM -0400, Geoff Thorpe wrote:
I think it was Alan Cox who (first) made the observation that eventually the sound would need to be part of X11 (and hence the sound server part of the X server), otherwise you'll always have synchronisation issues between video and audio. Obviously arts is in the running for this, but the crucial part will be the protocol details, and no doubt all the other sound daemons will race to bolt themselves on to such a definition. If it's good enough for video cards ...
BTW, I believe this was going to be one of the major talking points at some upcoming desktop symposium in Ottawa, but unfortunately I don't have any details handy (I heard it over a beer with the guy who was organising it, but I didn't take notes :-).
Then again, which "free X project" would be first to develop this? <evil grin>
What about something like MAS (http://www.mediaapplicationserver.net)? -- Ryan Underwood, <nemesis(a)icequake.net>
On April 21, 2004 05:21 pm, Ryan Underwood wrote:
What about something like MAS (http://www.mediaapplicationserver.net)?
Yeah, that'd probably do it :-) Cheers, Geoff -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/
You also need to check for the direct sound flag. If that is set and the format is not supported, then return the closest supported format. An open of the primary buffer should not fail regardless of the format. It should just return the closest supported format. Roderick Colenbrander wrote:
Hi,
This second patch fixes a wrong return value in the case a format isn't supported. Further it moves some traces to a different place to make debugging easier.
Roderick Colenbrander
------------------------------------------------------------------------ Name: alsa alsa Type: text/x-diff Encoding: 7bit
participants (8)
-
Geoff Thorpe -
Mike Hearn -
Mike Hearn -
Ove Kaaven -
Paul Davis -
Robert Reif -
Roderick Colenbrander -
Ryan Underwood