Closed: stable version out - get it here (http://www.foobar2000.org/components/view/foo_out_wasapi)
What is this?
This plug-in adds Windows Audio Session API exclusive mode output support, allowing bit-exact output and muting all other sounds. Windows Vista or newer required.
Notable changes from the 2.x series:
* Faster volume control
* 32bit integer mode if 32bit floating-point is not supported by the device
* Operates in two different modes, regular and event-driven - the latter seems to be more compatible with USB devices, but not supported by some other devices.
* Separate process sandbox for improved stability.
New in beta 6:
* Made internal buffer sizes tweakable through Advanced Preferences for hopefully better compatibility.
* Increased internal buffer size for event mode for hopefully better glitch resilience on most systems.
* Changed output mode naming (now: "WASAPI (push)" and "WASAPI (event)").
How to install:
Double-click the .fb2k-component file.
If the above does not load the component into foobar2000, read here (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:How_to_install_a_component).
Preemptive replies:
"I've installed the component using means other than mentioned above and it doesn't work" => no we don't want to hear about it.
"I can't install .fb2k-component because I'm running an old foobar2000 version" => nope we don't want to hear about it either.
"The component doesn't work, I run Windows XP" => WASAPI requires Windows Vista or newer.
Download:
Version 3.0 beta 6
Enjoy.
gave me error on my setup
Unrecoverable playback error: Unkonwn error (80070057)
Win7 64bit foobar2000 1.1.12 beta 5
Auzentech X-fi Forte
Thank you! Works perfect with Win7 64bit & foobar2000 1.1.11.
Added bonus: Now I can bitstream DTS files when using SPDIFER!
Thanks Peter for upgrading the component, i've only one stupid comment as actually there isn't a possibility for me to try it, it wasn't directly mentioned in the changelog and there isn't additional options for the component as it wasn't before also. Does it now use WaveRT if supported by the driver, so it can use low latency pull mode? For your answer, thanks in advance.
Thanks Peter!
It works good on Win7 x64 and E-MU 1820m (I was usually using ASIO). Latest Foobar beta: 1.1.12 Beta 6.
Will it update via normal Foobar way or I need to follow this tread?
You will need to download it from this topic until a stable release is uploaded to the components repository.
I have been trying to play back dts files through S/PDIF, to have it decoded for surround by my receiver. But I have problems. In theory this should work with this beta of WASAPI plus SPDIFER, shouldn't it?
I have two sound cards: an integrated Realtek card, plus EMU0404. My receiver is connected to the optical out of the Realtek card and the analogue out of the EMU card.
If I set the output to my Realtek card, I get an error message: device is in use. But now to the strange part: If I use the EMU card, I do get perfect 5.1 surround from dts files now. How could that happen?
However, only dts and ac3 files will play back from the EMU card. For all other files I have to switch to Realtek again.
Since I don't use the dts decoder, I can't tag the files, and they won't add to the library. Is there a solution for this?
gave me error on my setup
Unrecoverable playback error: Unkonwn error (80070057)
Win7 64bit foobar2000 1.1.12 beta 5
Auzentech X-fi Forte
Anybody else getting this? Seems to be isolated to Auzentech X-Fi cards, probably a driver bug, there's no E_INVALIDARG (80070057) defined for such scenario in the documentation.
Thanks Peter for upgrading the component, i've only one stupid comment as actually there isn't a possibility for me to try it, it wasn't directly mentioned in the changelog and there isn't additional options for the component as it wasn't before also. Does it now use WaveRT if supported by the driver, so it can use low latency pull mode? For your answer, thanks in advance.
The new WASAPI plug-in is entirely based on "event driven mode", or "pull mode" as you name it.
Anybody else getting this?
Yes me!
Unrecoverable playback error: Unkonwn error (80070057)
Win7 64bit foobar2000 1.1.12 beta 6
AMD Radeon HD 6670
Thanks for development of the WASAPI stuff! Best regards,
H
Thanks. It works for me just fine. Though also the old version worked without problems.
I tested the new component quickly on three different HW setups: Windows 7 32-bit & Terratec DMX 6Fire 24/96 PCI, Windows 7 64-bit & onboard Realtek HD Audio, and out of curiosity Windows 7 64-bit & an old USB connected Philips boombox that precedes Vista (this uses a default Windows 7 device driver).
Thanks. It works for me just fine. Though also the old version worked without problems.
I tested the new component quickly on three different HW setups: Windows 7 32-bit & Terratec DMX 6Fire 24/96 PCI, Windows 7 64-bit & onboard Realtek HD Audio, and out of curiosity Windows 7 64-bit & an old USB connected Philips boombox that precedes Vista (this uses a default Windows 7 device driver).
Found an issue.
When browsing the Internet (IE9) while listening to Music with Foobar 1.1.11 & Wasapi Plugin 3.0 Beta, the Music sometimes skips (a few milliseconds noise is heard). This never happened with Wasapi 2.1 Plugin.
I can't reproduce it, it happens occasionally. I'm not sure, but I believe it only happens when a site has heavy loading or Flash Ads are playing.
Upgraded, seems to work. (Win Vista 32bit, fb 1.1.11)
Found an issue.
When browsing the Internet (IE9) while listening to Music with Foobar 1.1.11 & Wasapi Plugin 3.0 Beta, the Music sometimes skips (a few milliseconds noise is heard). This never happened with Wasapi 2.1 Plugin.
I can't reproduce it, it happens occasionally. I'm not sure, but I believe it only happens when a site has heavy loading or Flash Ads are playing.
Thanks for the report, I was kind of expecting this issue to show up.
Event mode in fact provides
worse protection against CPU usage spikes than push mode (as seen in earlier versions of this plug-in) because we queue less data with the driver at a time and must wake up and send more data at regular intervals. However, event mode seems necessary to peacefully cooperate with certain devices, USB ones in particular.
Manually overriding priorities of fb2k & WASAPI host exe processes in task manager might help you. I'll look into other means to improve resistance to system resource usage spikes.
Actually, now I noticed that there are lots of artifacts in the form of "crackling", it sounds like an old broken speaker.
Actually, now I noticed that there are lots of artifacts in the form of "crackling", it sounds like an old broken speaker.
Here too. Terrible crackling.
Win7 32Bit, Foobar2000 1.1.11, M-Audio Delta Audiophile 2496 (driver V. 6.0.8)
I assume this plug-in will only support exclusive mode? I was wondering if there could be any benefits of using wasapi (non-exclusive) over directsound (lower latency maybe?).
I assume this plug-in will only support exclusive mode?
working together a foobar2000 (exclusive mode) & other programs (non-exclusive)
with the previous version of plugin this was not possible
LynxTWO card
(http://uploads.ru/i/o/F/6/oF6nw.png)
Working fine here (i3 2100, W7 x86), no crackling whatsoever but...
Does this plugin check available sampling rates against the driver reported DS capabilities? I'm asking because like with V 2.1 it doesn't let me play 88.2 or 176.4KHz with my Xonar ST whereas J River plays both sample rates fine on the same configuration using WASAPI.
Also I have another issue with my Musiland 02 Monitor 02US, J River allows 32bit on all sample rates in WASAPI mode but if I try to use 32bit with V 2.1 or 3.0 beta Foobar freezes having to set it to 24bit max in order to play, not that it is a problem but I was wondering why if hardware supports it why the plugin doesn't.
Would it be possible to add a configuration section under "Advanced" where we could tune the plugin to our system?
Cheers
I assume this plug-in will only support exclusive mode?
working together a foobar2000 (exclusive mode) & other programs (non-exclusive)
with the previous version of plugin this was not possible
When I try to use non-exclusive mode I get the error "Unrecoverable playback error: Unsupported stream format: 44100 Hz / 24-bit / 4 channels" (I mirror stereo to the back channels, but the error occurs regardless of sample rate/bit-depth/number of channels). Works perfectly fine in exclusive mode (which is why I asked if this plug-in was ever intended to work in non-exclusive mode).
I assume this plug-in will only support exclusive mode? I was wondering if there could be any benefits of using wasapi (non-exclusive) over directsound (lower latency maybe?).
The component is for exclusive mode only. There is no benefit to develop shared mode component, the output would not be any more direct than with directsound. And latency is irrelevant in an audio player.
I'm asking because like with V 2.1 it doesn't let me play 88.2 or 176.4KHz with my Xonar ST whereas J River plays both sample rates fine on the same configuration using WASAPI.
Also I have another issue with my Musiland 02 Monitor 02US, J River allows 32bit on all sample rates in WASAPI mode but if I try to use 32bit with V 2.1 or 3.0 beta Foobar freezes having to set it to 24bit max in order to play, not that it is a problem but I was wondering why if hardware supports it why the plugin doesn't.
It looks like J River does some signal processing (resampling) in its outputs. Your Xonar does not support the sample rates you mentioned (specs (http://www.asus.com/Multimedia/Audio_Cards/Xonar_Essence_ST/#specifications)). And your Musiland does not support 32-bit output, 24-bits is max (specs (http://www.musiland.com.cn/index.php/Product/show/id/137)).
Is it possible that I hear a difference in sound between 2.1 & 3.0 beta?
Version 2.1 uses push mode and it is problematic to at least USB devices. If the buffer is too large the output will have glitching. There shouldn't be any other difference. There may be differences in response speed to volume changing and some glitching on seek/pause caused by driver issues, but normal playback is identical.
Under some hardware configurations low latency pull mode (wavert) won't function properly at all. It has to be supported by hardware and its software driver (WV/7 logo), only in this case there shouldn't be any crackling or skips in sound during playback and this new component will represent an advantage over the old one. For all other configs, push mode (wasapi component 2.1) is the way to go.
This would be good to realize before reporting some unlegitimate problems.
(http://msdn.microsoft.com/en-us/windows/hardware/gg463068.aspx, the part about WaveRT Event-Driven Mode Support)
It looks like J River does some signal processing (resampling) in its outputs. Your Xonar does not support the sample rates you mentioned (specs (http://www.asus.com/Multimedia/Audio_Cards/Xonar_Essence_ST/#specifications)). And your Musiland does not support 32-bit output, 24-bits is max (specs (http://www.musiland.com.cn/index.php/Product/show/id/137)).
Forget the specs of both cards Case, they were written according to the original drivers and have not been updated to show current capabilities. The Xonar ST has been accepting those sampling rates for over 2 years, same for my other D2X Xonar. The same happens with the Musiland specs, the USB receiver chip will accept 32bit from driver V. 2.2.xxxx onwards though the DAC IC is a 24bit TI PCM1793 so the last 8 bits will be truncated at some point.
The component is for exclusive mode only. There is no benefit to develop shared mode component, the output would not be any more direct than with directsound. And latency is irrelevant in an audio player.
Another question, does mixing always happen with DirectSound/WASAPI (shared mode) even if only one audio stream is active? Basically my ideal scenario would be use exclusive mode (no mixing) only when foobar is the sole active audio stream, but use shared mode if there are multiple audio streams active. Is this scenario feasible (it seems unlikely)? Perhaps on song change foobar could check to see if the device was in use or not?
Forget the specs of both cards Case, they were written according to the original drivers and have not been updated to show current capabilities. The Xonar ST has been accepting those sampling rates for over 2 years, same for my other D2X Xonar. The same happens with the Musiland specs, the USB receiver chip will accept 32bit from driver V. 2.2.xxxx onwards though the DAC IC is a 24bit TI PCM1793 so the last 8 bits will be truncated at some point.
For the component the sampling rate is irrelevant. It just opens the device with requested specs and handles errors if they are returned. Do you see those non-working rates listed in Default Format dropdown of the Xonar's output properties?
As for the 32-bit data, foobar uses float for that. I assume your card thinks it can handle it but chokes on it. I simply get error explaining that the format is not supported. Anyway, you shouldn't be bothered by that when it offers no benefits over the 24-bit format.
For the component the sampling rate is irrelevant. It just opens the device with requested specs and handles errors if they are returned. Do you see those non-working rates listed in Default Format dropdown of the Xonar's output properties?
As for the 32-bit data, foobar uses float for that. I assume your card thinks it can handle it but chokes on it. I simply get error explaining that the format is not supported. Anyway, you shouldn't be bothered by that when it offers no benefits over the 24-bit format.
Nope, those rates are not reported by the dropdown properties but work fine with the ASIO plugin (2.1.1 and 1.2.7) so the card's hardware handles them just fine, the software/drivers could be a different story though maybe they can't handle those rates with WASAPI.
As to the 32bit thing, I agree there is nothing to be gained by using it and I'm noth bothered at all, I was just curious why it works with the other player and not with the plugin, in fact, in this case 44.1/32 is even reported by the dropdown properties.
Another question, does mixing always happen with DirectSound/WASAPI (shared mode) even if only one audio stream is active? Basically my ideal scenario would be use exclusive mode (no mixing) only when foobar is the sole active audio stream, but use shared mode if there are multiple audio streams active.
Earlier, I described a situation with LynxTWO card - work foobar2000 in exclusive mode with others audio streams in shared mode.
maybe it depends on the hardware
Nope, those rates are not reported by the dropdown properties but work fine with the ASIO plugin (2.1.1 and 1.2.7) so the card's hardware handles them just fine, the software/drivers could be a different story though maybe they can't handle those rates with WASAPI.
Exactly the same story with Xonar D1
Jackal29a, do you have Media Center DSPs configured like this (http://i.imgur.com/9O9oJ.png)?
I also have the "Unrecoverable playback error: Unkonwn error (80070057)" issue. Creative X-Fi Titanium HD (not surprised).
Win7SP1 x64 Foobar 1.1.11
Jackal29a, do you have Media Center DSPs configured like this (http://i.imgur.com/9O9oJ.png)?
I do when I play PCM files but have to limit both sample rate and bit depth when I play DSD because it is decoded at 64/352.8 and my soundcards don't accept that format. When playing DSD I set >192K to be downsampled to 88.2 and bit depth to 24 or 32 depending on soundcard.
While this version does fix the double click issue moving between flac and mp3 files, it has caused the player to just hang - at first at the end of a track and now even while playing a track. I switched to DS and the player is fine.
If you need me to get you some debug, let me know the steps I need to setup the log output as the console currently does not show any error.
The above soundcards that"support" 32 bit PCM are doing that via driver downsample. The hardware (DAC chip) that is present on those cards - Cirrus Logic CS4398 for front and Cirrus Logic CS4362 for rest - cannot accept 32 bit PCM. And none of the DAC's on market can accept 32 bit float.
IMO keep it at 24 bit to get the best quality.
Jackal29a, do you have Media Center DSPs configured like this (http://i.imgur.com/9O9oJ.png)?
From said image:
“Sound can be output in any format. For example, you can listen to an audio CD in 5.1 surround at 32-bit / 192 kHz.”
What could possibly be the use of this? I’ll entertain the possible exception of pseudo-surround generated by a DSP; but I cannot think of any reason to upsample CDDA to such ridiculously high levels (even mentioning the possibility is silly enough).
I do when I play PCM files but have to limit both sample rate and bit depth when I play DSD because it is decoded at 64/352.8 and my soundcards don't accept that format.
What do you use to decode DSD? I wasn’t aware that the main decoders offered output at such high settings.
Jackal29a, do you have Media Center DSPs configured like this (http://i.imgur.com/9O9oJ.png)?
From said image:
“Sound can be output in any format. For example, you can listen to an audio CD in 5.1 surround at 32-bit / 192 kHz.”
What could possibly be the use of this? I’ll entertain the possible exception of pseudo-surround generated by a DSP; but I cannot think of any reason to upsample CDDA to such ridiculously high levels (even mentioning the possibility is silly enough).
The configuration Case posted in the pic assures that the decoded signal is sent "as is" to the the output without any further processing. I never use upsampling so I can't answer the 5.1@32/192 question.
I do when I play PCM files but have to limit both sample rate and bit depth when I play DSD because it is decoded at 64/352.8 and my soundcards don't accept that format.
What do you use to decode DSD? I wasn’t aware that the main decoders offered output at such high settings.
J River converts DSD (2.8224MHz/1bit) to 64/352.8 PCM by default when not bitsreaming to a DSD capable DAC, nothing done or selected by the user, that is JRiver's standard DSD->PCMconversion.
(http://i36.photobucket.com/albums/e43/Jackal29/JRMC.jpg)
As no DAC I know of can handle such output, downsampling and/or truncating are necessary. There a few recent DACs that can take 32/352.8 or 32/384 PCM from DXD files but none I know of can deal with 64bit dignals.
In the pic output is configured to downsample anything hogher than 192K to 88.2 (1/4th in this case) and bitdepth truncated to the Xonar's maximum ASIO accepted value (32bits ).
Actually, now I noticed that there are lots of artifacts in the form of "crackling", it sounds like an old broken speaker.
Here too. Terrible crackling.
Win7 32Bit, Foobar2000 1.1.11, M-Audio Delta Audiophile 2496 (driver V. 6.0.8)
The same situation here, just like old broken speakers.
Windows Server 2008, foobar2000 1.1.12 beta 5, Conexant 20585 SmartAudio HD.
Works fine without "crackling" in the first place with my external USB device which is a FiiO E7. After several minutes, it goes wrong with output with awful noises.
It looks like J River does some signal processing (resampling) in its outputs. Your Xonar does not support the sample rates you mentioned (specs (http://www.asus.com/Multimedia/Audio_Cards/Xonar_Essence_ST/#specifications)). And your Musiland does not support 32-bit output, 24-bits is max (specs (http://www.musiland.com.cn/index.php/Product/show/id/137)).
Asus Xonar D1http://www.asus.com/Multimedia/Audio_Cards...#specifications (http://www.asus.com/Multimedia/Audio_Cards/Xonar_D1/#specifications)
foobar2000 & foo_out_asio also work with the 32-bit output
although also not supported by the specification
(http://uploads.ru/i/V/Z/1/VZ1O6.png) (http://uploads.ru/i/A/H/q/AHq3f.png)
I think a configurable output bitdepth like the one in uLilith player could be useful for both the WASAPI and ASIO plugins:
(http://i36.photobucket.com/albums/e43/Jackal29/ulilith.jpg)
I've also tested my my Xonar with uLilith and it works with 32bit integer in either WASAPI or ASIO but 32bit floating point is a no go, the Musiland 02 works with both in either output mode so there is something not quite right in 3.0b as I can't play 32bit with the Xonar (unsupported format message) nor with the Musiland (Foobar crashes).
Topic split (http://www.hydrogenaudio.org/forums/index.php?showtopic=95104)
Tested with foobar 1.1.11 and Traktor Audio 2 soundcard and had the same crakling problem as described above.
Get back to the precious version which is great !! (except the delay in volume management).
Another question, does mixing always happen with DirectSound/WASAPI (shared mode) even if only one audio stream is active? Basically my ideal scenario would be use exclusive mode (no mixing) only when foobar is the sole active audio stream, but use shared mode if there are multiple audio streams active.
Earlier, I described a situation with LynxTWO card - work foobar2000 in exclusive mode with others audio streams in shared mode.
maybe it depends on the hardware
This doesn't make sense to me. If foobar is in exclusive mode, that'll be the only allowable audio stream (isn't that the purpose of exclusive mode? ). If "give exclusive mode applications priority" is unchecked and I try to play a song in foobar (with other audio streams active), foobar will throw an error "device in use" (which I assume is the outcome Peter expected). My question was is it possible for foobar to only engage exclusive mode if no other audio streams are active, otherwise use shared mode (I assume probably not, but it's worth a shot to ask).
Moofasa~
I am surprised, but it works that way
"give exclusive mode applications priority" checked
foobar2000 & foo_out_asio also work with the 32-bit output
although also not supported by the specification
There is absolutelly no use of setting 32 bit audio an the above cards. It is just a label in your software and probably worse audio quality:
The above soundcards that"support" 32 bit PCM are doing that via driver downsample. The hardware (DAC chip) that is present on those cards - Cirrus Logic CS4398 for front and Cirrus Logic CS4362 for rest - cannot accept 32 bit PCM. And none of the DAC's on market can accept 32 bit float.
IMO keep it at 24 bit to get the best quality.
SoNic67
I agree with you
Beta 2 available, see the original post for details.
Due to the differences between beta 1 and beta 2, beta 1 is still available for download, as it may actually work better for some users; please report such cases so I can decide on which approach to take in the future versions.
Beta 2 available, see the original post for details. Due to the differences between beta 1 and beta 2, beta 1 is still available for download, as it may actually work better for some users; please report such cases so I can decide on which approach to take in the future versions.
this one works. but sometimes sound stutters on 6ch 24bit 96khz samples.
Beta 2 available, see the original post for details.
Due to the differences between beta 1 and beta 2, beta 1 is still available for download, as it may actually work better for some users; please report such cases so I can decide on which approach to take in the future versions.
Hi Peter, is the int/float negotiation in beta2 automatic? if so it doesn't work with neither my Xonar ST nor with the Musi 02US.
Will it possible to have 2 separate entries in the output bithdepth so it can be done manually?
Does Event driven work with 32bit Int.?
Cheers
(...) it doesn't work with neither my Xonar ST nor with the Musi 02US.
Full error message please.
(...) it doesn't work with neither my Xonar ST nor with the Musi 02US.
Full error message please.
With the Xonar I get the "Unrecoverable playback error: Unsupported stream format: 96000 Hz / 32-bit / 2 channels" type whereas with the 02US Foobar hangs and shuts down. This happens on both b1 & b2
Win7 64bit foobar2000 1.1.12 beta 6, WASAPI Output Beta 2
AMD Radeon HD 6670
Hi Peter!
With the new Beta 2, playback of all of my high resolution audio files (.flac) is working like a charme :
- 5.1, 5.0, 4.0, 2.1, 2.0 Channel 24bit/96Khz -> working
- 2.0 Channel 24bit/88,2KHz -> working
- 2.0 Channel 24bit/192KHz -> working
- 2.0 Channel 24bit/176,4kHz -> working
- 2.0 Channel 16bit/44,1KHz -> working
- 5.1 Channel DTS .wav 24bit/44,1KHz -> working
Big Thanks for your effort
Helios
I have written this in another topic. I will post it again, here, maybe you can help me.
Hello everyone!
I am using Foobar2000 with wasapi or kernel streaming, and an Asus Xonar D2 soundcard. When Foobar is running, any other browser sounds
are turned off. But when I close a page that contains/produces any sounds, i.e. I close a YouTube page, I get a very distinct
pop in my speakers.
This goes for any browser I use. This problem manifests whenever I close a page that contains sounds, movies, or any flash
content. The problem does not occur if I use the classic windows mixer. Has anyone encountered this issue?
Thank you!
Beta 2 working well here (Windows 7 64bit, Focusrite Saffire 6 USB audio interface).
I have written this in another topic.
Which will be deleted as a duplicate post, if this one turns out to be relevant here. For that reason, and since you haven’t specified, can you confirm that this issue persists in either of the latest beta versions?
Yes, the problem is still present.
With beta2 my FiiO E7 USB DAC plays files fine. Just after playing the first seconds, there will be mute for several seconds.
I don’t think that qualifies as “fine”…
Thread split: 32-bit capable DACs (http://www.hydrogenaudio.org/forums/index.php?showtopic=95159)
I don’t think that qualifies as “fine”…
After that mute for a few seconds, everything is fine. I just hope this issue can be fixed with the next version.
Beta 2 available, see the original post for details.
Due to the differences between beta 1 and beta 2, beta 1 is still available for download, as it may actually work better for some users; please report such cases so I can decide on which approach to take in the future versions.
I hope Peter, you'll decide for pull mode (event driven) approach or at least merge the codes into one component with an option to set an approach..
First of all, thanks a lot for the work being done on this update, Peter. It is very helpful for asynchronous USB DAC owners like me.
The event driven mode approach (beta 1) works well so far with my HRT Music Streamer II USB DAC as long as I set the hardware buffer to 50ms. The random glitches are gone. With Wasapi v2.1, the DAC regularly stuttered in random intervals.
I'll try beta 2 with my DAC and report back my findings.
Just to update, beta 2 does not work with my HRT Music Streamer II USB DAC at all. I press play and nothing happens. I have rolled back to beta 1 for now. I did notice some slight clicking noises in rare occasions but I'm not so sure. I'll try to listen some more to confirm my findings.
Thanks Peter and co. Beta 2 work just fine on my Lexicon Lambda. The only problem is when i open "Recording Devices" tab, under "Sound" if the default format doesn't match the sample rate of my playback, the sound will become distorted and buzzy, just like the previous Wasapi 2.x. With Asio, no such problem exist. But i think that's more like Lambda driver bug, than Wasapi plugin.
Inspired by jologsmaster, I just re-tested beta1 with my FiiO E7 usb DAC with software buffer of 200ms instead of the default value as 1000ms, the glitches just gone. Not tested with my crappy onboard sound card yet. My best guess is that the glitches may be caused by the software buffer requested all the time by foobar2000. If that's the case, beta1 may be better than beta2 once software buffer set to a shorter value.
I have Windows 7 64-bit, and a Creative X-Fi Titanium sound card. I'm currently using beta 2 that uses the polling based option. Between low latency event and polling based, which would work best out of the two for my X-Fi Titanium card? I currently have my output data format set to 24-bit. From what I've read, it seems that one beta is for usb sound cards, and the other beta is for a dedicated PCI express sound card (what I have).
There was a thread split recently, but I think it's worth mentioning the final results here. The post link is: http://www.hydrogenaudio.org/forums/index....st&p=797345 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=95247&view=findpost&p=797345)
In short: could you please ignore the "format unsupported error" when calling IsFormatSupported(), and only accept that it's an error when Initialize() complains instead? In other words: IsFormatSupported() is "unreliable".
Beta 2 seems much more stable. The only problem I have is that if I turn off the receiver that the PC is plugged into via HDMI then this will usually crash FB instead of just defaulting to no output or even better would be the default.
For me beta1 is more stable than beta2 speak of USB audio devices once set foobar2000's buffer to a smaller one. It would be perfect if the glitches using with onboard soundcard can be resolved based on beta1 and the buffer problem can also be resolved.
For me beta1 is more stable than beta2 speak of USB audio devices once set foobar2000's buffer to a smaller one
That part is irrelevant to beta 1 as it always uses a small hardware buffer. The buffer size you set in the player is a secondary software buffer. If having such a buffer is a problem, then I don't want to live in this world any more.
Exactly, the buffer size adjusted in the player options is a secondary one. Two betas available are not comparable, as they use different approaches for configurations relevant for them. But pull mode is newer approach with advantages over push mode in better skip protection and less processor cycles needed, the problem is it won't function on non "pull mode ready" configurations correctly or at all.
Beta 3 posted, see initial post for details.
Sweet!
Beta 3 can now send uncompressed multi-channel audio through my sound card's fake S/PDIF playback device. Both regular and event driven seem to work fine.
Thanks for applying the changes
beta3 event-driven mode, it went wrong just like beta1 once been disturbed by another cpu-hog program and will not be able to recover.
And the new beta3 event-driven mode is still not working well with the onboard sound-card of my laptop.
This beta 3.0 is working better with the VST plug-ins. More responsive but still "lock" the VST like it was happening sometimes before (pressing ctrl+alt+del to bring up the task manager will lock it).
Blue Cat FreqAnalyst x64...
DSD file play requires 49MB memory and 1-2% CPU (Core2Duo E7300).
beta 3 is working perfect with the Xonar ST!!! Not only I can finally play 88.2 and 176.4KHz, which wasn't possible with previous WASAPI versions, but also 32bit output works in either mode (push/pull), amazing job Peter. Did you do as Ceniza suggested and forced the otuput regardless of what the drvier reports?
32bit ouput is still a no go with the Musiland 02 and Foobar crashes and shuts down as soon as I hit play in either mode, but as it works with the Xonar I guess it is the Musiland drivers that don't want to play nice though it works in JRMC.
Thanks Peter, really appreciated.
beta3 event-driven mode, it went wrong just like beta1 once been disturbed by another cpu-hog program and will not be able to recover.
Known, it is being looked into.
And the new beta3 event-driven mode is still not working well with the onboard sound-card of my laptop.
Event-driven mode apparently doesn't cooperate with lots of different hardware at all, there's no reason to use it if the other mode works for you.
32bit ouput is still a no go with the Musiland 02 and Foobar crashes and shuts down as soon as I hit play in either mode, but as it works with the Xonar I guess it is the Musiland drivers that don't want to play nice though it works in JRMC.
Do you get a "foobar2000 has crashed" dialog? I'm having trouble finding matching crash reports.
Do you get a "foobar2000 has crashed" dialog? I'm having trouble finding matching crash reports.
Yes I do, here is the log (there is a dmp file too in the log folder):
Illegal operation:
Code: C0000005h, flags: 00000000h, address: 01BB274Bh
Access violation, operation: read, address: 00000024h
Call path not available.
Code bytes (01BB274Bh):
01BB270Bh: 52 FF 50 0C 8B 4D D4 8B 01 FF 10 03 45 D8 D9 83
01BB271Bh: 90 00 00 00 51 D9 1C 24 50 8B 07 56 8B CF FF 10
01BB272Bh: 50 FF 15 74 51 BC 01 8D 75 E0 8D 83 B4 00 00 00
01BB273Bh: E8 A0 0A 00 00 C6 45 FC 04 8B 08 83 C1 08 8B 01
01BB274Bh: FF 50 24 8B 8B C0 00 00 00 03 4D E8 8B 75 E0 3B
01BB275Bh: C8 1A C0 FE C0 88 45 0B 85 F6 74 08 E8 94 E8 FF
01BB276Bh: FF 8A 45 0B 84 C0 74 30 8D 75 DC 8D 83 B4 00 00
01BB277Bh: 00 E8 5F 0A 00 00 8B 00 8D 8B B4 00 00 00 E8 90
Stack (0D84FC28h):
0D84FC08h: 02710C90 0D84FC58 0D84FCB4 01BB5682
0D84FC18h: 0B96CFEC 0D84FC94 01BB31EC 01BB2740
0D84FC28h: 02710D2C 02710C90 0B969708 00000000
0D84FC38h: 01BCB274 00000000 00000000 00000000
0D84FC48h: 00000000 00000000 00000000 00000000
0D84FC58h: 01BCB2C0 0B96CFE8 0000089D 02712DB8
0D84FC68h: 01BCB2A0 0B969B48 0000113A 0000113A
0D84FC78h: 0000AC44 00000002 00000003 01BCB2B0
0D84FC88h: 0D84FC68 00000000 77B7215C 0B96CFE8
0D84FC98h: 00000008 0000089D 00000000 0000089D
0D84FCA8h: 0D84FCCC 01BC4524 00000004 0D84FCD8
0D84FCB8h: 01BB292F 00000000 02710C94 75ED6A72
0D84FCC8h: 02710D2C 0D84FD0C 01BC43C7 00000000
0D84FCD8h: 0D84FD18 01BB23DD 00000000 00000000
0D84FCE8h: 0B969708 0D84FD68 77B5E115 000002A4
0D84FCF8h: 000002B0 77B96500 77B96536 00000000
0D84FD08h: 0B969708 0D84FD30 01BC455F 00000000
0D84FD18h: 0D84FD3C 01BB3A67 00000000 00000000
0D84FD28h: 0B969708 0D84FD20 0D84FD6C 01BC4354
0D84FD38h: 00000000 0D84FD44 01BB3A89 0D84FD7C
Registers:
EAX: 00000000, EBX: 02710C90, ECX: 0B96CFF0, EDX: 0B969B48
ESI: 0D84FC94, EDI: 0D84FC58, EBP: 0D84FCB4, ESP: 0D84FC28
Crash location:
Module: foo_out_wasapi
Offset: 274Bh
Loaded modules:
foobar2000 loaded at 00A10000h - 00BC9000h
ntdll loaded at 77B40000h - 77C7C000h
kernel32 loaded at 773B0000h - 77484000h
KERNELBASE loaded at 75ED0000h - 75F1A000h
COMCTL32 loaded at 74C60000h - 74DFE000h
msvcrt loaded at 76DA0000h - 76E4C000h
GDI32 loaded at 775F0000h - 7763E000h
USER32 loaded at 774F0000h - 775B9000h
LPK loaded at 77C90000h - 77C9A000h
USP10 loaded at 76F00000h - 76F9D000h
SHLWAPI loaded at 77490000h - 774E7000h
DSOUND loaded at 6CD60000h - 6CDD2000h
ADVAPI32 loaded at 77CA0000h - 77D40000h
sechost loaded at 77D40000h - 77D59000h
RPCRT4 loaded at 76E50000h - 76EF1000h
ole32 loaded at 76FA0000h - 770FC000h
WINMM loaded at 72750000h - 72782000h
POWRPROF loaded at 74700000h - 74725000h
SETUPAPI loaded at 779A0000h - 77B3D000h
CFGMGR32 loaded at 75D80000h - 75DA7000h
OLEAUT32 loaded at 77720000h - 777AF000h
DEVOBJ loaded at 75F20000h - 75F32000h
UxTheme loaded at 74AE0000h - 74B20000h
SHELL32 loaded at 75FF0000h - 76C3A000h
zlib1 loaded at 5A4C0000h - 5A4D4000h
shared loaded at 6FB90000h - 6FBBB000h
imagehlp loaded at 775C0000h - 775EA000h
dbghelp loaded at 62DA0000h - 62E8B000h
COMDLG32 loaded at 77100000h - 7717B000h
gdiplus loaded at 74950000h - 74AE0000h
Secur32 loaded at 75A70000h - 75A78000h
SSPICLI loaded at 75BB0000h - 75BCB000h
CRYPT32 loaded at 75DB0000h - 75ECD000h
MSASN1 loaded at 75D40000h - 75D4C000h
WINHTTP loaded at 716E0000h - 71738000h
webio loaded at 71690000h - 716DF000h
IMM32 loaded at 75FD0000h - 75FEF000h
MSCTF loaded at 777B0000h - 7787C000h
CRYPTBASE loaded at 75C20000h - 75C2C000h
foo_input_monkey loaded at 10000000h - 10049000h
foo_dynamic_range loaded at 008F0000h - 00958000h
foo_freedb2 loaded at 69EB0000h - 69EF0000h
foo_dsp_xgeq loaded at 6FC60000h - 6FC9C000h
foo_rgscan loaded at 69E60000h - 69EAB000h
foo_dsp_std loaded at 69C80000h - 69CC8000h
foo_input_dvda loaded at 69C20000h - 69C7B000h
foo_input_sacd loaded at 69B70000h - 69C14000h
foo_ui_std loaded at 69A80000h - 69B65000h
MSIMG32 loaded at 74240000h - 74245000h
foo_unpack loaded at 6FC30000h - 6FC5F000h
foo_fileops loaded at 69A30000h - 69A77000h
foo_out_asio loaded at 01AF0000h - 01B26000h
foo_abx loaded at 01B60000h - 01B92000h
foo_albumlist loaded at 699D0000h - 69A2C000h
foo_out_wasapi loaded at 01BB0000h - 01BD6000h
foo_converter loaded at 697F0000h - 6986C000h
foo_hdcd loaded at 68A80000h - 68AC3000h
foo_input_std loaded at 67510000h - 67670000h
foo_cdda loaded at 68A30000h - 68A7E000h
CLBCatQ loaded at 77690000h - 77713000h
sud loaded at 660B0000h - 6616B000h
ADVPACK loaded at 61340000h - 6136E000h
VERSION loaded at 751D0000h - 751D9000h
DUI70 loaded at 74890000h - 74942000h
PROPSYS loaded at 74B20000h - 74C15000h
avrt loaded at 746C0000h - 746C7000h
MMDevApi loaded at 747D0000h - 74809000h
CRYPTSP loaded at 75730000h - 75746000h
rsaenh loaded at 754D0000h - 7550B000h
AUDIOSES loaded at 6F7D0000h - 6F806000h
audiokse loaded at 60E00000h - 60E72000h
WINTRUST loaded at 75D50000h - 75D7D000h
ksuser loaded at 6D2E0000h - 6D2E4000h
WindowsCodecs loaded at 745A0000h - 7469B000h
msxml3 loaded at 67850000h - 67983000h
cmasiop loaded at 02620000h - 0266C000h
Stack dump analysis:
Address: 01BCB274h (foo_out_wasapi+1B274h), symbol: "foobar2000_get_interface" (+16554h)
Address: 01BCB2C0h (foo_out_wasapi+1B2C0h), symbol: "foobar2000_get_interface" (+165A0h)
Address: 01BCB2A0h (foo_out_wasapi+1B2A0h), symbol: "foobar2000_get_interface" (+16580h)
Address: 01BCB2B0h (foo_out_wasapi+1B2B0h), symbol: "foobar2000_get_interface" (+16590h)
Address: 77B7215Ch (ntdll+3215Ch), symbol: "EtwEventEnabled" (+D9h)
Address: 01BC4524h (foo_out_wasapi+14524h), symbol: "foobar2000_get_interface" (+F804h)
Address: 01BB292Fh (foo_out_wasapi+292Fh)
Address: 75ED6A72h (KERNELBASE+6A72h), symbol: "InterlockedCompareExchange" (+F8h)
Address: 01BC43C7h (foo_out_wasapi+143C7h), symbol: "foobar2000_get_interface" (+F6A7h)
Address: 01BB23DDh (foo_out_wasapi+23DDh)
Address: 77B5E115h (ntdll+1E115h), symbol: "RtlAddMandatoryAce" (+32Ch)
Address: 77B96500h (ntdll+56500h), symbol: "wcsnicmp" (+C74h)
Address: 77B96536h (ntdll+56536h), symbol: "wcsnicmp" (+CAAh)
Address: 01BC455Fh (foo_out_wasapi+1455Fh), symbol: "foobar2000_get_interface" (+F83Fh)
Address: 01BB3A67h (foo_out_wasapi+3A67h)
Address: 01BC4354h (foo_out_wasapi+14354h), symbol: "foobar2000_get_interface" (+F634h)
Address: 01BB3A89h (foo_out_wasapi+3A89h)
Address: 01BB7DA4h (foo_out_wasapi+7DA4h), symbol: "foobar2000_get_interface" (+3084h)
Address: 01BB8D40h (foo_out_wasapi+8D40h), symbol: "foobar2000_get_interface" (+4020h)
Address: 01BB7E2Eh (foo_out_wasapi+7E2Eh), symbol: "foobar2000_get_interface" (+310Eh)
Address: 773FED6Ch (kernel32+4ED6Ch), symbol: "BaseThreadInitThunk" (+12h)
Address: 77BA377Bh (ntdll+6377Bh), symbol: "RtlInitializeExceptionChain" (+EFh)
Address: 77410651h (kernel32+60651h), symbol: "UnhandledExceptionFilter" (+0h)
Address: 77410651h (kernel32+60651h), symbol: "UnhandledExceptionFilter" (+0h)
Address: 77B5E115h (ntdll+1E115h), symbol: "RtlAddMandatoryAce" (+32Ch)
Address: 77BA374Eh (ntdll+6374Eh), symbol: "RtlInitializeExceptionChain" (+C2h)
Address: 01BB7DCAh (foo_out_wasapi+7DCAh), symbol: "foobar2000_get_interface" (+30AAh)
Address: 01BB7DCAh (foo_out_wasapi+7DCAh), symbol: "foobar2000_get_interface" (+30AAh)
Address: 74616E72h (WindowsCodecs+76E72h), symbol: "WICConvertBitmapSource" (+BE06h)
Address: 74614420h (WindowsCodecs+74420h), symbol: "WICConvertBitmapSource" (+93B4h)
Address: 77772F2Fh (OLEAUT32+52F2Fh), symbol: "VarMonthName" (+B72h)
Address: 74642E30h (WindowsCodecs+A2E30h), symbol: "IWICColorContext_InitializeFromMemory_Proxy" (+1957h)
Address: 76207473h (SHELL32+217473h), symbol: "RunAsNewUser_RunDLLW" (+199Ah)
Address: 74657373h (WindowsCodecs+B7373h), symbol: "IWICColorContext_InitializeFromMemory_Proxy" (+15E9Ah)
Address: 76616C66h (SHELL32+626C66h), symbol: "StrStrW" (+27695Fh)
Address: 776C0000h (CLBCatQ+30000h), symbol: "OpenComponentLibraryOnMemEx" (+D83h)
Address: 76880000h (SHELL32+890000h), symbol: "StrStrW" (+4DFCF9h)
Address: 76860000h (SHELL32+870000h), symbol: "StrStrW" (+4BFCF9h)
Address: 74240000h (MSIMG32+0h)
Address: 74686769h (WindowsCodecs+E6769h), symbol: "IWICColorContext_InitializeFromMemory_Proxy" (+45290h)
Address: 74656C77h (WindowsCodecs+B6C77h), symbol: "IWICColorContext_InitializeFromMemory_Proxy" (+1579Eh)
Address: 00A26F00h (foobar2000+16F00h)
Address: 77772F2Fh (OLEAUT32+52F2Fh), symbol: "VarMonthName" (+B72h)
Address: 72756F6Ch (WINMM+6F6Ch), symbol: "CloseDriver" (+1AFh)
Address: 76000000h (SHELL32+10000h), symbol: "SHEnableServiceObject" (+1B27h)
Address: 008F0200h (foo_dynamic_range+200h)
Address: 0090008Bh (foo_dynamic_range+1008Bh)
Address: 00A4009Fh (foobar2000+3009Fh)
Address: 00AE00A9h (foobar2000+D00A9h)
Address: 00B700B2h (foobar2000+1600B2h)
Address: 01B101A9h (foo_out_asio+201A9h), symbol: "foobar2000_get_interface" (+15439h)
Environment:
App: foobar2000 v1.1.12a
UI: Default User Interface 0.9.5
Components:
Core (2012-05-26 22:31:52 UTC)
foobar2000 core 1.1.12a
foo_abx.dll (2012-03-23 13:26:41 UTC)
ABX Comparator 1.3.4
foo_albumlist.dll (2012-05-26 22:30:18 UTC)
Album List 4.5
foo_cdda.dll (2012-05-26 22:30:02 UTC)
CD Audio Decoder 3.0
foo_converter.dll (2012-05-26 22:29:44 UTC)
Converter 1.5
foo_dsp_std.dll (2012-05-26 22:30:22 UTC)
Standard DSP Array 1.0
foo_dsp_xgeq.dll (2012-05-06 23:32:08 UTC)
Graphic Equalizer 0.3.7
foo_dynamic_range.dll (2012-03-23 13:22:33 UTC)
Dynamic Range Meter 1.1.1
foo_fileops.dll (2012-05-26 22:28:54 UTC)
File Operations 2.1.3
foo_freedb2.dll (2012-05-26 22:30:28 UTC)
freedb Tagger 0.6.4
foo_hdcd.dll (2012-05-18 08:41:40 UTC)
HDCD decoder 1.14
foo_input_dvda.dll (2012-03-23 13:22:46 UTC)
DVD-Audio Decoder and Watermark Detector 0.4.11
foo_input_monkey.dll (2012-06-05 08:04:08 UTC)
Monkey's Audio Decoder 2.1.6
foo_input_sacd.dll (2012-05-29 06:17:52 UTC)
Super Audio CD Decoder 0.5.10
foo_input_std.dll (2012-05-26 22:29:50 UTC)
Standard Input Array 1.0
foo_out_asio.dll (2012-03-31 06:27:28 UTC)
ASIO support 1.2.7
foo_out_wasapi.dll (2012-06-05 06:31:55 UTC)
WASAPI output support 3.0 beta 3
foo_rgscan.dll (2012-05-26 22:29:48 UTC)
ReplayGain Scanner 2.1.2
foo_ui_std.dll (2012-05-26 22:30:12 UTC)
Default User Interface 0.9.5
foo_unpack.dll (2012-05-26 22:29:16 UTC)
ZIP/GZIP/RAR Reader 1.6
Machine specifications:
OS: Windows 6.1.7601 Service Pack 1 x86
CPU: Intel® Core i3-2100 CPU @ 3.10GHz, features: MMX SSE SSE2 SSE3 SSE4.1 SSE4.2
Audio: Altavoces (3- MUSILAND Monitor 02 US); Altavoces (ASUS Xonar Essence ST Audio Device)
Thanks for the log, but from now on please auto-submit your crash reports, it really makes my job easier this way. Any specific reason why you didn't auto-submit this one? (Or perhaps you did but it didn't come thru somehow?)
If you cannot or don't want to auto-submit the reports, please share the minidump file (using the uploads forum (http://www.hydrogenaudio.org/forums/index.php?showforum=42)).
Thanks for the log, but from now on please auto-submit your crash reports, it really makes my job easier this way. Any specific reason why you didn't auto-submit this one? (Or perhaps you did but it didn't come thru somehow?)
If you cannot or don't want to auto-submit the reports, please share the minidump file (using the uploads forum (http://www.hydrogenaudio.org/forums/index.php?showforum=42)).
sorry for that, I'm not getting the Foobar error message that allows to send the files but Windows' one (it crashes hard) so I¡ll have to upload manually next time.
If you still have the .dmp file you got along with the log that you posted, please upload this dmp file for me to look into.
Bug fixed, thank you for your patience.
Beta 4 posted, see the initial post for details.
Beta 4 posted, see the initial post for details.
You nailed it with Event Mode, it works fine now I can get 32bit at any sample rate with the Musiland as well.
Something still wrong in push mode but no biggie by me, case closed.
This is working great!
On a Go-vibe USB DAC that only accepts 16-bit, 44.1 kHz,
event-driven mode works fine with the software buffer set at any value, with isolated stutters when the CPU (Yonah) is placed on high load. SpeedStep/FID/VID switching in RMClock.
The usual mode works at software buffer values >= 100 ms. The audio file permanently pauses when this setting is too low (90 ms or less) until it is adjusted higher again.
It seems low buffer values in the regular ("push") mode are non-functional regardless of your hardware right now due to certain assumptions in the code, please don't use less than 200ms as there's really no point in doing so.
It seems low buffer values in the regular ("push") mode are non-functional regardless of your hardware right now due to certain assumptions in the code, please don't use less than 200ms as there's really no point in doing so.
Again, you hit the bull's eye once more. I increased the buffer to 500ms a works perfect.
Funny how some hardware is able to go well beyond its original specs. Neither of my sound cards is supposed to be doing what they are in fact doing (and extremely well actually), no that there is any real audible advantage to it but it cerntainly proves a point, never fully trust manufacturer's specs.
Actually the manufacturer specs are correct. The "32 bit" mode is a useless one, Windows trims those 32 bit to whatever your card supports (24 bit probably) - by trowing-away extra bits.
WASAPI event (http://wiki.jriver.com/index.php/WASAPI).
Actually the manufacturer specs are correct. The "32 bit" mode is a useless one, Windows trims those 32 bit to whatever your card supports (24 bit probably) - by trowing-away extra bits.
WASAPI event (http://wiki.jriver.com/index.php/WASAPI).
I'm think you are mixing apples and oranges. In WASAPI mode Windows throws nothing away, if Fooabgr sends 32bit that is exactly what the soundcard will receive, it works, full stop if it didn't you'll get an error and no sound. The soundcards as a
DEVICE DO indeed accept 32bit input which they truncate before sending to the DAC IC. One thing is the PCI/PCIe/USB receiver and another the DAC chip itself, the fromer can accept 32bit and the second may or may not (ESS9016/18, AKM4399, PCM1795, etc.). The Musiland accepts the 32bit and, if enabled, proceeses it using its DSP in 32 bit before down coverting tp 24 bit for its PCM1793 24bit DAC.
Anyway, this is OT so lets stop it here.
* MMCSS use for hopefully better glitch prevention.
* Event driven mode now recovers correctly after a glitch caused by high CPU usage.
Magic explained
Enjoy.
What an understatement, Peter! just opened a HydrogenAudio account to thank you for beta 4: it's like having one's earwax removed. While people argue that bits are bits, miniscule dropouts are dropouts -- and (unlucky?) some hear them all.
Many thanks!
----
Win7/32, antiquated Merom laptop, FiiO E10, event mode, magic!
Well done Peter, well done...
Beta 4 is perfect!
Tested now for 6 hours without glitches or something other wrong things.
Soundcard: Creative X-Fi USB 5.1 Surround -> PAX USB 2.25 driver...
What an understatement, Peter! just opened a HydrogenAudio account to thank you for beta 4: it's like having one's earwax removed.
Without adjusting the volume slider in foobar2000, WASAPI output will be a lot louder than DirectSound (at least on my machine), and increases in loudness were found to be equal with a higher perceived audio quality (http://www.hydrogenaudio.org/forums/index.php?showtopic=79249).
He claims he was having audio dropouts, which would be completely different than just loudness differences, and far more annoying.
Either that or it’s some alternative way to describe the alleged presence of jitter, something that is unlikely to have been an issue without WASAPI anyway, and something (else) that is not compliant with TOS #8 unless substantiated.
Kohlrabi made a very good point that might explain the perception (if it actually exists), although I hadn’t heard about WASAPI being louder by default: is this another benefit of modern Windows’ audio system?
Kohlrabi made a very good point that might explain the perception (if it actually exists), although I hadn’t heard about WASAPI being louder by default: is this another benefit of modern Windows’ audio system?
There is probably no difference in volume if you have set your output device to 100% in Windows Mixer, now that I think of it. Which I haven't done.
Yeah, I never noticed a volume discrepancy when I was forced to use WASAPI over DS for a few years. Kholrabi's observation was probably all a result of volume mixer differences.
Sorry I wasn't clear, and thanks to the kind souls who took care of that:
He claims he was having audio dropouts, which would be completely different than just loudness differences, and far more annoying.
Exactly: WASAPI sounds ~10dB louder than DS here, but who cares?
Either that or it’s some alternative way to describe the alleged presence of jitter, something that is unlikely to have been an issue without WASAPI anyway, and something (else) that is not compliant with TOS #8 unless substantiated.
Indeed, it used to sound like (aperiodic) jitter
as if coming from last sample in buffer "latched" on DAC till the next buffer starts to clock out or - more likely - a PLL "smoothing" / dropping sync on data stream interruption. "Alleged" is very appropriate in front of the J-word here, as I took no direct or indirect measurements.
And now, thanks to Peter, we don't need any
I'm think you are mixing apples and oranges. In WASAPI mode Windows throws nothing away, if Fooabgr sends 32bit that is exactly what the soundcard will receive, it works, full stop if it didn't you'll get an error and no sound. The soundcards as a DEVICE DO indeed accept 32bit input which they truncate before sending to the DAC IC. One thing is the PCI/PCIe/USB receiver and another the DAC chip itself, the fromer can accept 32bit and the second may or may not (ESS9016/18, AKM4399, PCM1795, etc.). The Musiland accepts the 32bit and, if enabled, proceeses it using its DSP in 32 bit before down coverting tp 24 bit for its PCM1793 24bit DAC.
Anyway, this is OT so lets stop it here.
The DRIVER throws away the extra bits that DAC cannot use. You rely on driver to handle that "conversion" properly instead of feeding it the right signal... Musiland doesn't have any "32 bit DSP" like you stated:
http://www.musiland.com.cn/index.php/Product/show/id/137 (http://www.musiland.com.cn/index.php/Product/show/id/137)
"Monitor02 US sound card supports a maximum audio processing of
24Bit/192KHz and adopts D/A conversion chip with SNR and dynamic range as high as 113dB to provide HI-FI sound effect of analog output."
They know that they use PCM1793 (http://www.ti.com/lit/ds/symlink/pcm1793.pdf) that is only 24 bit capable.
But probably you think that the manufacturers of both DAC and sound card are stupid.
And no, is not OT, is related strictly of the 32 bit send to the cards that don't have the physical capabilities for that.
PS: My E-MU 1820m accepts the 32 bit, but I know that the whole hardware is a 24 bit pathway.
Wow. Beta 4 event mode works really well with my HRT Music Streamer II USB DAC at almost any hardware buffer setting. The clicking glitches have been eliminated. After listening to music for a few hours I did notice a momentary pause in the music once in a while.
I get stuttering with beta 4 in event driven mode if I have the CPU loaded 100% on both cores and then try and refresh a webpage in firefox. I have foobar thread priority at 7 (max, default). Everything seems ok in the other, 'normal' wasapi mode.
Edit: also getting some stuttering in normal wasapi mode. But it's like once every 30 mins or something. It's hard to reproduce.
WASAPI should no longer be louder in the just released foobar2000 v1.1.13.
Edit: fixed the version number.
I think that's a typo, make that foobar2000 v1.1.13 final
Anybody else getting app deadlocks when cycling between DS/WASAPI while playing?
(Problem seems to be somewhere deep in DirectSound code so it's not really my department)
No deadlocks. There's a noticeable cut in audio when switching outputs (among DS, WASAPI and WASAPI (Event)), but music always resumes fine.
PCM2702 USB DAC (Govibe), Win 7 SP1
With beta1 and beta4 i have noticed wrong channel mapping with my High Resolution 5.0 channel .flac files: Surround right doesn't work, it seems to be mapped to lfe! Playback is working fine with beta2! Not tested: beta3.
Win7 64/HP -> foobar2000 v1.1.13 -> Radeon HD 6670 -> HDMI Output -> A/V Receiver
BTW, the same odd behavior i have noticed with ASIO component!
For your information, nothing has changed regarding channel mapping in the recent versions; if you're seeing the exact same problem with ASIO, it sounds like the real issue is something else than fb2k and its output components.
No deadlocks with my USB DAC. I still get the occasional pauses during music playback though. I noticed the mute indicator of my DAC lights up whenever this happens.
Out_WASAPI v3.0 beta 4 runs smoothly here on Windows 7 x64. I'm able to select 32-bit output on a SoundBlaster XiFi Xtreme Music which I couldn't do with all previous releases, including v2.x.
Re occasional pauses and other glitches - do you also get similar glitches with plain DirectSound or are these WASAPI specific?
Anybody else getting app deadlocks when cycling between DS/WASAPI while playing?
(Problem seems to be somewhere deep in DirectSound code so it's not really my department)
I'm getting deadlocks, when switching from or to wasapi.
If it stops responding I can't even kill foobar with the process explorer.
I have submitted the crash report.
---
EMU0202 USB
Win7 x64
foobar2000 1.1.13 / foo_wasapi 3.0 beta 4
The pauses I'm getting are WASAPI specific.
Re occasional pauses and other glitches - do you also get similar glitches with plain DirectSound or are these WASAPI specific?
Only with WASAPI.
Adding an echo here: if there are stutters in playback, only in WASAPI (Event). As per your advice and my own desire for stutter-free playback, I've been using a buffer size of 3000 ms in FB2K.
Beta 5 posted. If you're still experiencing glitches, I'd like to know if they're better/worse than in beta 4.
Excellent! No more audio pausing with beta 5. No other problems encountered so far.
I experience a new problem with beta 5. If the sample rate or the number of channels of the next track is different, the new track keeps waiting at 0 seconds without progression. It seems like the output is not switched to the properties of the new track. By giving the play command it will start.
This does not happen when I switch back to DS.
-Windows Vista (up-to-date), Realtek HD Audio, Wasapi standard mode (event mode is not usable with this hardware/driver), Foobar2000 1.1.13-
The WASAPI 3 series solve the limitation of the buffer length that previously was present. It is now for instance possible to use a normal buffer length, regardless of the output sample rate and number of channels.
Although hardly audio skips any more, I noticed a glitch in the form of a small portion of audio being repeated a couple of times. I could not reproduce that, it might have been one of those moments when Windows wants to do something for itself.
Unfortunately beta5 didn't resolve the deadlock I'm experiencing, after switching between ds and wasapi.
It now has a different behaviour:
-foobar2000 closed, with delay.
-the wasapi64host was still running, and I couldn't kill it.
I experience a new problem with beta 5. If the sample rate or the number of channels of the next track is different, the new track keeps waiting at 0 seconds without progression. It seems like the output is not switched to the properties of the new track. By giving the play command it will start.
This does not happen when I switch back to DS.
For whatever it’s worth, someone else already reported (http://www.hydrogenaudio.org/forums/index.php?showtopic=95224) this or a very similar behaviour in v2.1 but said it was fixed by v3.0b1/2 (albeit accompanied by new problems, whose identities were never specified).
Tried beta 5 with the Xonar and the Musiland with 0 problems. I tried playing alternating different bit depth/SR tracks (44.1/16, 24/96, 48/16, etc.) and no glitches whatsoever but then I was neither getting any with b4.
B5 is as rock solid as b4 in my PC.
beta5 is slightly (but noticeably) worse than beta4 with stuttering in wasapi event mode.
Using Beta5 and am getting a lot of random crackling from both regular and even mode. Using a USB DAC (iBasso D4) on 1000ms for buffer length if this matters. Haven't tried changing it. WASAPI 2 plugin doesn't cause crackling unless I set the buffer too high.
Using Beta5 and am getting a lot of random crackling from both regular and even mode. Using a USB DAC (iBasso D4) on 1000ms for buffer length if this matters. Haven't tried changing it. WASAPI 2 plugin doesn't cause crackling unless I set the buffer too high.
Interesting. With what settings exactly are you able to use the old plug-in without crackling?
Unfortunately beta5 didn't resolve the deadlock I'm experiencing, after switching between ds and wasapi.
It now has a different behaviour:
-foobar2000 closed, with delay.
-the wasapi64host was still running, and I couldn't kill it.
Unfortunately, "process cannot be killed" bugs are outside the scope of what I can really help with, perhaps reporting this to Microsoft would help. At least it's an improvement that foobar2000 itself can terminate cleanly.
Will WASAPI ever add an option NOT to mute all other sounds?
Will WASAPI ever add an option NOT to mute all other sounds?
http://www.hydrogenaudio.org/forums/index....st&p=798260 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=95434&view=findpost&p=798260)
Using Beta5 and am getting a lot of random crackling from both regular and even mode. Using a USB DAC (iBasso D4) on 1000ms for buffer length if this matters. Haven't tried changing it. WASAPI 2 plugin doesn't cause crackling unless I set the buffer too high.
Interesting. With what settings exactly are you able to use the old plug-in without crackling?
Using the old pluging and setting the buffer to 2000ms would cause me problems. I believe I would get the same at 1500ms too. I was not able to turn it up high much after 1000ms without the old plugin causing problems. So with the WASAPI 2 plugin at the default 1000ms would work cleanly.
Alright so I played with Beta5 some more today with buffer set at 1000ms for both modes. I'm finding this a bit strange now... The normal mode started working fine without any glitches. Event mode will still have minor glitches when doing other stuff like browsing the web. I made a new post cause apparently I couldn't find the edit button.
* Enabled sandbox functionality for better stability (known to work-around fb2k deadlocks when cycling output modes).
WASAPIHost32 seen eating up to 5% of CPU (rare... 1% more common, yet hardly reproducible).
* Changed internal buffer sizes for hopefully better event-driven mode behavior.
Increased? Sounds
as if spectrum of jitter has shifted down in frequency (very speculative "as if").
* Increased MMCSS priority from "Playback" to "Pro Audio" for hopefully better glitch protection.
Would love to discount this as source of difference
(no other high-priority processing is going on system-wide, AFAIK).Thank you, Peter, for cracking this one step at a time.
-------
Win7/32SP1, old Merom laptop, Fiio E10, event, less magic than beta4.
Further testing with my Musiland 02 has shown that there are lots of clicks with both b4 and b5, moreso with high sampling rate tracks like 96KHz, they are not there with the Xonar ST (the soundcard I use 99.9% of the time) nor when using JRMC with either. This happens both in push and pull modes. I've played with buffer sizes (500-2000ms) and process priorities but it doesn't help. CPU usage is very low (<5%).
Another issue I have with both soundcards is that if I open another app with sound I get a loud "pop" as if Foobar's WASAPI hadn't true exclusive access, again, this doesn't happen with JRMC.
Beta 2 is working perfect with my USB DAC , but the others (Beta 4 and 5) could not work fine after a pause ?
Is there anybody have the same problem ?
^^^^ you should add which mode you are using in beta 4 and 5.
My USB DAC is working perfect at DS mode and WASAPI mode (Beta 2) but not at WASPI mode (Beta 4 and 5).
Beta 4 and 5 can work fine before a pause. Once pause and play I can get noise only.
Beta 2 is working perfect with my USB DAC , but the others (Beta 4 and 5) could not work fine after a pause ?
^^^^ you should add which mode you are using in beta 4 and 5.
What Mr. Duck was referring to: Do you use standard or "event" WASAPI output?
If I may add my 2 cents: The only valid version so far for me personally has been beta2. Why? Wasapi should not only give bit-perfect output but also provide bit-streaming. beta2 has been the only version which - in conjunction with the SPDIFER add-on - would bypass foobar2000's internal DTS decoding and bitstream the intact DTS stream to my receiver for it to decode. Arguably hardware DTS decoding is superior to software decoding, and working bit-streaming is what I personally hope to get out of the WASAPI component - preferably without SPDIFER.
^^^^ Both standard and event have the same problem . Thanks
Comments on beta4 and beta5, on 2 different USB soundcards/"DAC"s, and fixes:
My motherboard is a P35. My OS is Win7 64-bit. I prefer a large 3000ms buffer to ensure gap-free playback, as I might be playing Diablo 3 et al.
1. Audiophilleo 2
This device had skips/glitches/pops/clicks in the audio at random. It was not wasapi-specific. Happened on asio4all, kernel streaming, wasapi, or wasapi event mode. Could not get rid of the problem, no matter what buffer size, USB port, or USB hub. All USB hubs power management disabled.
I finally got rid of the problem with a Dynex 2-port USB PCI card. It now plays smoothly and consistently, no clicks whatsoever.
2. Gigalab Moon DAC MKII
The USB input on this device goes to a CMedia based section. It never has any issues with clicks/pops no matter what.
I have or had a number of USB/Firewire products over the years on prosumer brands (Edirol, Ego-Sys, M-Audio) that all supported native Steinberg ASIO, never a single glitch up to 24/192... I have not had to deal with audio pops/clicks since the ISA/SoundBlaster16/Pentium MMX days like 12-14 years ago.
If you have non wasapi-specific glitches, I would try a $20 usb pci card.
If I may add my 2 cents: The only valid version so far for me personally has been beta2. Why? Wasapi should not only give bit-perfect output but also provide bit-streaming.
What exactly is the difference between "bit-perfect output" and "bit-streaming"?
Also there was more than one cause, another contributor was the Belkin high-speed usb 2.0 hub. Some USB audio devices did not have error-free playback while on that hub.
I'm using AudioEngine's D1 DAC.
My best experience is using beta 4. Smooth as ever, no crackling whatsoever.
I play mostly flac files, some hi resolution ones as well.
Once I got kernel streaming playing smoothly, I focused on troubleshooting my wasapi playback glitches. In order to get wasapi beta 5 playing smoothly, I had to go into BIOS and disable C1E and EIST. Crossing my fingers on smooth wasapi audiophile2 usb playback, seems ok so far with those throttling disabled.
If I may add my 2 cents: The only valid version so far for me personally has been beta2. Why? Wasapi should not only give bit-perfect output but also provide bit-streaming.
What exactly is the difference between "bit-perfect output" and "bit-streaming"?
In my layman's terms the difference would be that bit-perfect would reproduce the inherent codified bits of any sound format without altering them while allowing for de-compression/de-codification while bit-streaming would be the ability of passing through undecoded bitstream formats like DTS, AC3, SACD etc. to be decoded by hardware. The accepted formats for bit-streaming also depend on the transport device like SPDIF, HDMI etc.
WASAPI as an interface - again in layman's terms - can do as little or as much of the above as one cares to program it with, I guess.
FYI, what you call "bit-streaming" everyone else calls "pass-through".
I understand version 3 follows in the footsteps PlayPcmWin (http://code.google.com/p/bitspersampleconv2/wiki/PlayPcmWinEn)?
FYI, what you call "bit-streaming" everyone else calls "pass-through".
Please provide supporting links when making absolute statements like this, like from Wikipedia. Anyhow, niggling about how to name the child doesn't further its development.
If I may add my 2 cents: The only valid version so far for me personally has been beta2. Why? Wasapi should not only give bit-perfect output but also provide bit-streaming.
It is bit perfect, HDCD flag passes corectly (and that is very sensitive to bit-perfect playback since it is the LSB).
Cannot edit my previous post but it was wrong. I found out that WASAPI was indeed working fine with my Musiland 02 in both modes, the problem I had was a due to a dodgy USB 3.0 port, moved it to another one and it is now fine with no clicks whatsoever.
DPC latency tool reports higher latency in WASAPI than in ASIO mode (80-95us Vs 45-65us) any one knows the reason why? as it is the same with the XOnar and the Musiland I don't think it is driver related.
Cheers
ASIO is expected to be fastest... if is native, included in the sound card drivers.
I'm also getting occasional glitches using WASAPI Beta 5 and my AudioEngine D1 listening with headphones. it's very hard to hear the glitches when listening to my speakers.
My output buffer is 2000ms and bit depth is 24.
I'm currently testing event mode.
I'm using AudioEngine's D1 DAC.
My best experience is using beta 4. Smooth as ever, no crackling whatsoever.
I play mostly flac files, some hi resolution ones as well.
After further testing, the only problems I'm experiencing is when I play "non conventional" combinations of bitrates and samplerates.
For instance, playing 24/96 flac is usually smooth (although more prone to errors due to cpu load), but playing 24/88 files is glitchy from the start.
if possible; please add an option to "run with high(est) process priority" --- like option of ASIO (v2.1.2) output plugin
thanks.
"if possible; please add an option to "run with high(est) process priority" --- like option of ASIO (v2.1.2) output plugin" - with beta5 this has been done already, it is sure now that possible clicks aren't caused by insufficient priority. My experience with onboard low latency-ready (event mode) audio under W7 (wavert supported - some Via or Realtek HD) is flawless playback also during heavy CPU load. I don't know the case with usb devices,no possibility for me to test it. I am more than sure, the same behavior will be also with pci/pci-e sound cards, that properly support this mode through their drivers.
I got a blue screen of death on windows 7 when using wasapi beta 3, 4, and 5. I realized that at all times it happened I was ripping a cd on dbpoweramp while playing music on foobar. Just wanted to share in case you could use that info for anything.
I'm using AudioEngine's D1 DAC.
My best experience is using beta 4. Smooth as ever, no crackling whatsoever.
I play mostly flac files, some hi resolution ones as well.
After further testing, the only problems I'm experiencing is when I play "non conventional" combinations of bitrates and samplerates.
For instance, playing 24/96 flac is usually smooth (although more prone to errors due to cpu load), but playing 24/88 files is glitchy from the start.
Beta 5 properly solved all my troubles.
I'm sticking with this one until someone forces me otherwise.
Update:
Beta 5 event mode still works perfectly with my HRT Musicstreamer II USB DAC with firmware rev 2.1.
Strictly 16-bit 44.1kHz FLAC/MP3/etc. file playback.
Foobar output settings at 1000ms buffer length and 24-bit output data format. DSP and Replaygain deactivated.
If I may add my 2 cents: The only valid version so far for me personally has been beta2.
I have to amend this. At least beta5 also does pass-through. However, through some trial-and-error I found that the DSP component "Advanced Limiter" seems to alter the stream to such an extent that passthrough may be impossible.
So, thumbs up for beta5!
I have to amend this. At least beta5 also does pass-through. However, through some trial-and-error I found that the DSP component "Advanced Limiter" seems to alter the stream to such an extent that passthrough may be impossible.
Adding DSPs will break passthrough in almost all cases.
Currently using beta 5 with no noticed issues so far. Operating system is Windows 7 Enterprise SP1, 64 bit. Buffer is set to 1000ms, onboard audio is a Realtek ALC269 with w/e my computer manufactures latest drivers are for it. All music played has all been FLAC, that was ripped from my personal CD collection using accuraterip, paranoid settings, and the recorded offset of my drive found via accuraterip's data base. So it's all 2 channel, 16 bit, 44100 Hz. Currently letting the realtek do its thing and going straight from the headphone jack via a 3.5 that y-splits to analog RCA into the wireless headphone transmitter for my gaming headphones (Turtlebeach x41 model). Just updated Foobar to 1.1.13 today. My testing yesterday was with 1.1.12 (also no issues).
Only question I have is the presence of both a WASAPIHost32.exe and a WASAPIHost64.exe in the WASAPI component folder. In task manager I see WASAPIHost64.exe running while playing music, is it safe to assume I can remove WASAPIHost32.exe with no issues?
I also have access to a USB soundcard if you'd like me to do any testing with that (its the Turtle Beach Amigo II, usually I only use it as an adapter to let me use my headphone mic w/ voiceplayback, but I could use it for audio playback testing.
I also have S/PDIF out (coaxial) but I'm waiting on a few components to arrive (should be sometime this week) before I start using it. Once I receive those components I can go SPDIF/coaxial out -> FiiO D3 DAC (via RCA) -> Schitt Valhalla -> Beyerdynamic DT-990 (600ohms) for additional testing (and my primary listening source).
Let me know if there's anything you'd like me to try specifically - currently I'm only using regular mode - not event. But I'm happy to help with testing on such a great component, thanks for your work on it!
(Sidenote: I typically set foobar2k to above normal priority within task manager as well, and I use no DSPs, foobar set to output at 16bits (since all the files I play are 16 bit I assume this is the proper choice))
Sorry for the double post - would edit in this report but I suppose to much time has passed to allow me to edit it.
Had issues with playback today, it began skipping, then came to a full stop for a few seconds after which it went back to skipping before I manually paused it. CPU was under a heavy load (60-70%), as well as RAM, and the program didn't actually crash; I suppose I was just asking the computer to do to much and it decided playback didn't need all that it was requesting. I would consider the skipping under that level of a CPU load to be a WASAPI fixable issue - as it merely needed to be recognized as higher priority, but since I wasn't monitoring the usage of my ram at the moment when this occurred I can't confirm that. I suspect that I simply demanded too much of my RAM while simultaneously having WASAPI output settings at a 1000ms buffer.
And despite foobar2k and the WASAPI.exe being run at above normal priority, its perfectly viable it wasn't a WASAPI issue - as the heavy load I told my computer to do was asking the iPod manager component of Foobar2k to wipe what was on my iPod (perhaps 6 gigs worth of music) and then convert 10.7 gigs worth of FLAC into ALAC and place it all on the iPod without actually creating permanent ALAC files on my computer. Sooooooo, maybe that was a bit much to handle since it was a request within foobar (giving it the same priority of the WASAPI.exe; not to mention the fact that the WASAPI has to ask for stuff from F2k).
Still, I figured it was worth mentioning, since it was the absolute first issue I've had with playback that could possibly be attributed to WASAPI v3 beta 5.
Also still curious if I can get rid of the WASAPIHost32.exe since I only ever see 64 operating within taskmanager. And still open to testing playback with my previously mentioned (not yet tested) available resources (USB sound card, or S/PDIF coax out to a DAC). I can attempt to replicate any issues anyone's having with v5 beta, as I have access to all the methods of playback I've seen mentioned up to this point.
Happy to help in anyway I can with this
-Bradapalooza
I'm convinced the basic goal of creating the component that works flawlessly with the right drivers (WaveRT) was done already. MMCSS usage was important step for utilizing all the possibilities WV/7 audio stack can give, so thanks for this.
The problem is, Peter tries to make it working on wider range of audio hardware and here could be difficult to make it right for all of them without the possibility to adjust the settings manually. Maybe it increases the complexity of the component, but with additional options of the component everyone can find the right values for his own piece of hardware.
My idea is to have the possibility to adjust manually these basic settings:
- data feed mode (pull-event or push-regular mode), this has been done already
- render thread task type (Audio, Pro Audio, Playback) because of the right priority
- latency in ms
With some non low latency-ready hardware and drivers Pro Audio setting together with very low latency value can cause too high CPU cycles and glitching, so it isn't universal setting and my own best experience with onboard audio is to use thread task type Audio and latency in 10-50 ms range, but these values can be unsuitable for another hardware, of course. All this can be solved with manual adjustment in component options window.
I wonder if somebody could help me. I have been using an HRT musicstreamer II for a while now, with foobar2000 and kernel streaming with a buffer of 50ms, as recommended by the manufacturer due to the asynchronous nature of the streamer. It was generally fine, but suffered occasional glitches.
I then found the event styale WASAPI plugin (the standard one was terrible in my setup), and was very pleased, not a single glitch with 16/44.1 flac after days of listening. I then played 24/96 flac files and all was fine for about 30 mins, then it started to glitch.
My question is whether my continued use of 50ms buffer is the correct choice. Given the pull nature of event style, do I need to set the buffer much higher instead of as low as possible, as was required for push mode.
Any insights or recomendations would be very gratefully received. I know I could experiment with the buffer size, but just thought someone on here could maybe help with this process given their knowledge of the difference between push/pull.
BTW, I am using beta 5.
Many thanks in advance.
Are you running the latest firmware on your HRT Musicstreamer II?
Are you running the latest firmware on your HRT Musicstreamer II?
Thanks for replying.
I am using firmware 2.1, which I think is the latest.
Anybody?
I wrote to HRT as well, but have had no response either.
Can I assume that there is no simple answer to whether asynchronous DACs need low or high buffers for event mode WASAPI?
HRT user here using WASAPI 3.0 Beta 5 event mode.
I usually stick with 16-bit 44.1khz audio files for the most part which is probably the main reason why I don't get those glitches anymore. I rarely switch to and from different formats on the fly.
I also have the hardware buffer set at 1000ms without any problems whatsoever. It seems like with beta 5, the hardware buffer settings don't matter much anymore.
Maybe you can try using a self powered USB hub with the DAC as well as a higher quality USB cable. HRT DACs are known to require quite a bit of power from the USB port to function properly.
Another thing is to make sure that the foobar2000 WASAPI output bit depth is set at the same bit depth with the sound format settings in the windows control panel and vice versa. That solved the muting issues that I was having recently.
Thanks mate.
Like you, I don't get any glitches at all with 16/44.1 flac. However, I do get occasional glitches with 24/96. Running from ramdisk does help, I'll just have to try and see if there is a sweet
spot for the buffer length when running High Def.
If I find one, I'll let you know.
Thanks again.
Been struggling all week with glitches on a USB port to a Fiio E17.
My home machine has been rock solid, however on my work machine it just glitched. Tried every beta at every setting I could think of. They all worked for a bit then glitched away.
I changed USB ports and the front one was better than one in the back, but still I got the glitches.
I checked the USB driver in the machine (HP Z400) and Widows reported that it was the best USB driver.
After a week of this I went to the HP site and found there was a later USB driver for the machine.
I installed it and the performace has been rock solid ever since. I haven't been able to actually get it to glitch on any setting so far, although I haven't tried anything to extreme.
TL;DR - If you are having issues with glitches over USB make sure you have the latest USB drivers installed on your machine.
HRT Music Streamer II with F/W 2.1, FB2000 1.1.13, WASAPI 3 beta5, Win7 64-bit.
Tried all possible combinations of Kernel Streaming, ASIO, WASAPI v2. Couldn't get glitch free playback unless I had buffer set really low (<50ms) Then I flashed F/W from 1.7 to 2.1 and installed WASAPI 3beta 5. Now I can get the buffer up to 1000ms without glitches. Also I don't know the difference between WASPI (Event) and regular WASPI but the (Event) works much better. Most of my files are 16-bit mp3 and FLAC/APE. I haven't tried any 24-bit files yet.
Sound from HRT into vintage gear is awesome.
Note that HRT MSII needs 250milliamp of clean current to do its job. Download the USBview app from their website to make sure its on it own bus and not sharing a USB port with some other device.
Thanks for all the work improving WASAPI for FB2000 Peter!
Thanks for all your replies.
I think I've got all possible areas of weakness covered, such as USB ports, cables etc.
I used to use asio with win xp and got it working perfectly. However, since upgrading (?!) to win 7 (same computer)
I've been having problems. The most reliable I found to be kernel streaming at 50ms buffer, which glitches rarely.
I was just hoping that event WASAPI would remove the glitches permenantly. I've tried playing with the buffer
and think that it is slightly better with a bigger buffer, which leads me to think that ''pull mode'' has different requirements
to ''push mode''.
since upgrading (?!) to win 7 (same computer) I've been having problems. The most reliable I found to be kernel streaming at 50ms buffer, which glitches rarely.
What are you talking about? There is no kernel streaming on Win 7.
http://wiki.hydrogenaudio.org/index.php?ti...rt_(foo_out_ks) (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Components/Kernel_Streaming_support_(foo_out_ks))
excerpt:
''This component was originally written for Windows 2000 and Windows XP. It is not guaranteed to cooperate with newer versions of Windows.
Kernel Streaming is known to work on certain Windows Vista and Windows 7 configurations, but not with devices having WaveRT drivers such as High Definition Audio Devices integrated with newer motherboards - such devices simply won't be shown on foobar2000's output device list as available KS devices.''
I was told to try this from HRT technical support, I told them I had win 7. I suppose I got lucky.
If I may add my 2 cents: The only valid version so far for me personally has been beta2.
I have to amend this. At least beta5 also does pass-through. However, through some trial-and-error I found that the DSP component "Advanced Limiter" seems to alter the stream to such an extent that passthrough may be impossible. So, thumbs up for beta5!
Argh, I have to amend this again. It only worked once, after updating from beta2 to beta5. I guess the port or whatchmacallit was still programmed the "right" way from beta2 after the update. After restarting Windows, no more pass-through.
Someone also reported that channels were only set correctly in beta2... maybe this could have something to do with it?
I assume this plug-in will only support exclusive mode?
working together a foobar2000 (exclusive mode) & other programs (non-exclusive)
with the previous version of plugin this was not possible
LynxTWO card
(http://uploads.ru/i/o/F/6/oF6nw.png)
ah, thanks for the help, it now works for me using those settings.
got a Lynx L22
So i have this testing question.
using Realtek ALC889A with S/PDIF (optical cabel)
When looking in the Realtek configuration options i can choose
16bit, 44100hz (cd)
to
24bit, 192000hz (studio)
and then also
Dolby Digital Live 5.1 (surround)
So i figured that i use the highest my card can do (24bit, 192000hz) and 24bit in wasapi foobar output, then 50-1000ms
on 3.0 beta 5 (event mode) it works the same but what about this DDL 5.1? the volume gets louder when turning it on but i don't know how it works together
with this WASAPI plugin. What should i use? 2-channel only?
// Hoppla
Hello,
Recently I found your new beta update but it didn't help with my long time problem. I have been using wasapi plugin 2.1 with some strange bass redirection problem (Flex bass) on 24/96 hirez audio files. Immediately after playing something above 44.1 KHz bass redirection stops working. Same problem with KS output. Everything ok on redbook files (16/44.1). I thought this is asus driver related issue but right after switching on primary or DS driver bass is here. I'm using Xonar d2x (7.12.8.1794 driver) card on win 7 ultimate with 24 bit output. It's seems that this is some kind of never ending story for me. Anybody else having the same issue? Thanks for help.
I'm using AudioEngine's D1 DAC.
My best experience is using beta 4. Smooth as ever, no crackling whatsoever.
I play mostly flac files, some hi resolution ones as well.
After further testing, the only problems I'm experiencing is when I play "non conventional" combinations of bitrates and samplerates.
For instance, playing 24/96 flac is usually smooth (although more prone to errors due to cpu load), but playing 24/88 files is glitchy from the start.
Beta 5 properly solved all my troubles.
I'm sticking with this one until someone forces me otherwise.
Been using beta 5 for more than a month now.
Very good results.
The only problem I've encountered is glitches caused during the closing of google chrome tabs.
I'm using win7x64.
mine glitches everytime when I browse through each folder in window explorer, so annoying. If i don't do anything on the computer, and leave foobar plays the music, then there's no problem. I'm using win7x64 with eClaro.
mine glitches everytime when I browse through each folder in window explorer, so annoying. If i don't do anything on the computer, and leave foobar plays the music, then there's no problem. I'm using win7x64 with eClaro.
That's nothing new if I'm not mistaken. WASAPI is working in exclusive mode which means that nothing has access to soundcard exept foobar while playing. That includes system sounds when you browse your folders and any other devices attempt to use your soundcard are blocked. Just try to play any flash video on youtube while foobar playing with wasapi out and you'll hear absolutely nothing. Just disable your system sounds in windows for opening folders. Hope that helps. Correct me if I'm wrong....
Added bonus: Now I can bitstream DTS files when using SPDIFER!
Hi Sandrine !
May you help me how to config to bitstream DTS file to receiver ?
@notfourgo - A bit OT, but have a look here: http://www.ga.cba.pl/spdif_w7.html (http://www.ga.cba.pl/spdif_w7.html)
With the beta2 version of the WASAPI plugin and foo_spdifer, foobar2000 will not decode dts by itself but stream it to your receiver. Downside: You temporarily lose any tags while a file is playing.
@Sandrine
tks yr reply.
I used beta5 vesion of wasapi but I am not successful. Let me try with beta2.
Beta 5 seems to work OK for me except there is about a 2 sec delay before sound is heard after a pause. The time and bars move right away, but the sound does not start for about 2 secs after.. Is this normal? Same thing happens even on a re position into the current track.
It plays fine using DS output.
Note - multi-channel flac tracks do not have this delay and go out as PCM fine. The 2 channel tracks with or without Ozone 4 inline have the delay.
Sandrine - any help on the delay issue.
I am using an ACER 1802T I7 Ultrabook with HDMI output to my receiver - all formats are working just perfect - this is the only issue. Is anyone else seeing this issue?
Also I wrap all of my DTS files in .flac wrapper - They are not converted to flac just wrapped - is there any way of bit streaming them to the receiver?
Beta 6. I'm hoping to get this over with and release a stable version next.
Peter, I've tried new beta 6 with both my Xonar ST and the Musiland 02US (USB), it works great with both and no issues to report just a question, why is latency higher with than with ASIO? in case of the Xonar it jumps from 40-60uS using ASIO to 115-125uS using WASAPI Event (playing a DFF file with SACD plugin 0.6.0 and DSD2PCM = 176.4) and with the Musiland from 60-70uS to 100-110uS (using DPCtool)
Cheers
All of your releases so far has no problem or glitch with my Lexicon Lambda USB + Windows 7 x64.
Works perfect with foobar2000 v1.15 beta1 using WASAPI Event on Win 8 Pro X64
Thanks!
It's out now:
http://www.foobar2000.org/components/view/foo_out_wasapi (http://www.foobar2000.org/components/view/foo_out_wasapi)
No essential changes since beta 6.
Topic closed.