:o 1.6.7 beta 8 => Exclusive=> Unrecoverable playback error: Unsupported format ! !
:'( Please Fix It ASAP !
How about a little more information on why this happened? OS, DAC, driver, file playing etc.
I got a similar error when using the beta 8 for the first time.
Opening track for playback: "D:\Music\xxxxxx Music\Singles\C\City and Colour - Rain When I Die.m4a"
Soft fader output failure: Unsupported format
Unrecoverable playback error: Unsupported format
to fix it i needed to click the reset page button on the output page.
Actually not fixed. when i play a song after opening foobar2000 I get the following error.
Opening track for playback: "D:\Music\xxxxxxx Music\Singles\C\City and Colour - Rain When I Die.m4a"
Unrecoverable playback error: Unsupported format
but when i try and play the track again it works. If i close foobar2000 and reopen it will behave the same way, error on first play and work on the second play.
Core (2021-06-17 18:18:26 UTC)
foobar2000 core 1.6.7 beta 8
foo_albumlist.dll (2021-06-17 18:17:54 UTC)
Album List 1.6.7 beta 8
foo_bitcompare.dll (2021-03-04 04:26:38 UTC)
Binary Comparator 2.2
foo_cdda.dll (2021-06-17 18:17:54 UTC)
CD Audio Decoder 1.6.7 beta 8
foo_converter.dll (2021-06-17 18:17:54 UTC)
Converter 1.6.7 beta 8
foo_dop.dll (2020-02-02 17:28:14 UTC)
iPod manager 0.7.2
foo_dsp_eq.dll (2021-06-17 18:17:54 UTC)
Equalizer 1.2.2
foo_dsp_meiercf.dll (2018-01-06 10:27:18 UTC)
Meier Crossfeed 1.1.1
foo_dsp_std.dll (2021-06-17 18:17:54 UTC)
Standard DSP Array 1.6.7 beta 8
foo_facets.dll (2011-08-18 20:06:16 UTC)
Facets 1.0
foo_fileops.dll (2021-06-17 18:17:58 UTC)
File Operations 1.6.7 beta 8
foo_freedb2.dll (2021-06-17 18:17:54 UTC)
Online Tagger 0.8
foo_headphone_eq.dll (2020-08-07 04:16:30 UTC)
MathAudio Headphone EQ 1.4.4
foo_input_monkey.dll (2019-11-19 22:13:18 UTC)
Monkey's Audio Decoder 2.3.1
foo_input_std.dll (2021-06-17 18:18:04 UTC)
FFmpeg Decoders 4.3.1
Standard Input Array 1.6.7 beta 8
foo_musicbrainz.dll (2021-05-12 01:09:18 UTC)
MusicBrainz Tagger 0.4.7
foo_onewaysync.dll (2020-04-20 11:19:28 UTC)
One Way Sync 0.7.0
foo_rgscan.dll (2021-06-17 18:17:58 UTC)
ReplayGain Scanner 1.6.7 beta 8
foo_simplaylist.dll (2011-08-18 20:01:36 UTC)
SimPlaylist 1.0
foo_ui_std.dll (2021-06-17 18:18:08 UTC)
Default User Interface 1.6.7 beta 8
foo_unpack.dll (2021-06-17 18:18:08 UTC)
ZIP/GZIP/RAR/7-Zip Reader 1.6.7 beta 8
foo_verifier.dll (2020-07-01 22:34:34 UTC)
File Integrity Verifier 1.4
foo_wave_minibar_mod.dll (2021-05-09 04:15:18 UTC)
Waveform Minibar (mod) 1.0.45
Can confirm. I get the same error:
Opening track for playback: "D:\MP3\_CD-Backup\VA\VA - The Power - Greatest Party Hits [981872 8]\VA - The Power - Greatest Party Hits.cue" / index: 14
Unrecoverable playback error: Unsupported format
Noted, thanks for reporting.
Some things clearly went sideways in yesterday's build.
Beta 9 posted, the problem has been fixed.
For future reference, old beta downloads work - just edit the version number in the link.
Beta 9, exclusive mode works. high CPU when paused. Thank you Peter for all the hard work.
Yes, high CPU usage with exclusive mode on pause with fading enabled in beta 9. With Fading disabled CPU usage is OK.
Yes, high CPU usage with exclusive mode on pause with fading enabled in beta 9. With Fading disabled CPU usage is OK.
Beats me why fading makes a difference.
fb2k v1.6.7 beta 9
Fading mode - Disabled
Windows 10 21H1
1. Primary Sound Driver [exclusive] - No sound
Speakers (Intel SST Audio Device (WDM)) [exclusive] - No sound
Speakers (Sound Blaster Play! 3) [exclusive] - Ok
Primary Sound Driver - Ok
Intel SST Audio Device (WDM) - Ok
Speakers (Sound Blaster Play! 3) - Ok
2. CPU usage is higher during pause than during playback - for [exclusive] only.
The first play error is gone now but as others have said very high cpu usage (25% - 30%) when paused in exclusive mode with smooth seeking enabled. CPU usage is fine when paused with smooth seek disabled.
Foobar2000 1.6.7 Beta 9
Win 10 Build 21390.2025
(voicemeeter potato 3.0.1.8 ) / Komplete audio 1, ASIO
Hi I just wanted to report that I got 'pulsating' sound when in exclusive mode, sound is fine when not in exclusive mode.
Beta 10 posted, pause CPU usage bug fixed, thanks for reporting.
Foobar2000 1.6.7 Beta 9
Win 10 Build 21390.2025
(voicemeeter potato 3.0.1.8 ) / Komplete audio 1, ASIO
Hi I just wanted to report that I got 'pulsating' sound when in exclusive mode, sound is fine when not in exclusive mode.
Please try:
https://www.foobar2000.org/temp/BeepExclusive.exe
Does it play a clean beep for you, or glitch?
Beats me why fading makes a difference.
Fading is implemented as a layer between real output and fb2k code.
Individual outputs have nothing to do with fading now, though enabling fading does change the behaviors of code talking to the output, which exposed this specific bug in new WASAPI code.
You can use fading even with ASIO and alike (verified, works with ASIO).
For me all problems with exclusive mode are gone in beta 10.
Please try:
https://www.foobar2000.org/temp/BeepExclusive.exe
Does it play a clean beep for you, or glitch?
It glitches
Windows10 20H2
Default: SPDIF OUT (TEAC USB HS ASYNC AUDIO DEVICE) [exclusive]
Foobar2000 1.6.7 Beta 6 OK
Foobar2000 1.6.7 Beta 7 and 8 Exclusive=> Unrecoverable playback error: Unsupported format ! !
Foobar2000 1.6.7 Beta 9 and 10 Unrecoverable playback error: Unsupported stream format: 192000 Hz / 32-bit / 2 channels (0x3)
Is there a solution?
Beta 9 & 10 fixed the "unsupported format" error in exclusive for me. However, playback fails when transitioning between files with different bit depth or resolution when smooth seek is turned on. No errors, but either large gaps in playback or just outputs noise. A pause and then start again fixes it. With smooth seek turned off I no longer have any issues. (This in Windows 10 using a Chord Qutest DAC.)
Beta 9 & 10 fixed the "unsupported format" error in exclusive for me. However, playback fails when transitioning between files with different bit depth or resolution when smooth seek is turned on. No errors, but either large gaps in playback or just outputs noise. A pause and then start again fixes it. With smooth seek turned off I no longer have any issues. (This in Windows 10 using a Chord Qutest DAC.)
Same here (Windows 10 21H1 x64, S.M.S.L SU-8 DAC).
Thanks for the reports.
Please document any more issues that you find, all of these will be addressed next week.
Only issues I can't currently help with is those where BeepExclusive.exe also fails; I'll just drop warnings about old foo_out_wasapi to help troubleshooting these.
Beta 9 & 10 fixed the "unsupported format" error in exclusive for me. However, playback fails when transitioning between files with different bit depth or resolution when smooth seek is turned on. No errors, but either large gaps in playback or just outputs noise. A pause and then start again fixes it. With smooth seek turned off I no longer have any issues. (This in Windows 10 using a Chord Qutest DAC.)
I'm also getting gaps in playback when playback goes from one file to another with different sampling rate. And by gaps, I mean playback gets these weird stalls a few times a second. I have Smooth Seeking off, because it causes delay when starting playback by double-clicking a track.
Accidental double-post. Please delete.
In beta 10 the stuttering issue when switching from 44100 16bit tracks to 96000 24bit tracks in exclusive mode is still present.
The light on the DAC switches to the correct color for 96000 when the track changes.
fb2k v1.6.7 beta 10
How to reproduce:
1. Output Device: Primary Sound Driver [exclusive]
2. Enable smooth seeking...
3. Load playlist attached
4. Click Play stream "Energy Star Night"
After an error occurs, playback will go to the next stream. The sound will be jerky.
This does not happen for beta 6.
fb2k v1.6.7 beta 10
How to reproduce:
1. Output Device: Primary Sound Driver [exclusive]
2. Enable smooth seeking...
3. Load playlist attached
4. Click Play stream "Energy Star Night"
After an error occurs, playback will go to the next stream. The sound will be jerky.
This does not happen for beta 6.
I was able to reproduce that. Seems smooth playback breaks playback. A feature I don't use but notable.
Also changes in sample rate trigger it but if a resampler is chained in the DSP section it prevents it. Changes in the number of channels triggers it as well but is worked around with a DSP in the chain, both of which I typically do regardless of exclusive mode or not but I can see where users would have a problem here.
Thanks for all the details.
Problems with smooth output vs sample rate changes confirmed, will be fixed in beta 11 tomorrow.
Thanks for all the details.
Problems with smooth output vs sample rate changes confirmed, will be fixed in beta 11 tomorrow.
Peter, thank you for all the work you are doing and especially for open communication with all of us beta testers. It has given me some insight as to how an individual developer works.
with beta 11 now I get "Unrecoverable playback error: Unsupported stream format: 44100 Hz / 24-bit / 2 channels (0x3)" with output data format 24-bit. It is fine with beta 10 and also with WASAPI output support component
foobar2000 1.6.7 beta 11
RAL-DSDHA5, DENON DA-310USB
Unrecoverable playback error: Unsupported stream format: 44100 Hz / 24-bit / 2 channels (0x3)
FOSTEX HP-A4, FOSTEX HP-A4BL
The noise is still terrible.
Likewise 'Unrecoverable playback error: Unsupported stream format: 44100 Hz / 24-bit / 2 channels (0x3)' whether playing 16 or 24 bit file or with smooth seeking enabled or disabled.
RME HDSPE AIO Pro, latest v21 firmware and 438 drivers on Win10. Analogue output.
Multiple PCs full of soundcards and I still can't test 24bit-in-32bit that some devices want.
Beta 12 posted, regression fixed, thanks for reporting so quickly.
Many Thanks Peter.
foobar2000 1.6.7 beta 12
RAL-DSDHA5, DENON DA-310USB
No Problem. It will be played good
----------
FOSTEX HP-A4, FOSTEX HP-A4BL
The noise is still terrible.
Likewise, fixed here.
Thank you!
Aaagh .......
I wrote too soon.
The files I tested with originally were 24-44 (classical) and they do indeed now play without error.
However, a range of 24-88 and 24-96 files (contemporary) all return 'Unrecoverable playback error: Unsupported stream format: 88200 Hz / 24-bit / 96000 Hz / 24-bit / 2 channels (0x3) (as appropriate) when using Exclusive mode, whether smooth seeking enabled or not and whether the output data format is selected as 24 bit or, for test, 16 bit.
All files play properly when non-exclusive mode is selected.
Sorry.
Note that exclusive output - like all output plugins of the sort - doesn't perform any resampling of its own; if your device isn't agreeing with the sample rate of your audio files, errors happen. This is currently the intended behavior.
I'll think of some solution for this for post-1.6.7, perhaps negotiate some optimal rate to resample to.
Many Thanks Peter.
foobar2000 1.6.7 beta 12
RAL-DSDHA5, DENON DA-310USB
No Problem. It will be played good
----------
FOSTEX HP-A4, FOSTEX HP-A4BL
The noise is still terrible.
Thanks for confirming.
As for FOSTEX, looks like I'll have to resurrect the advanced preferences option, to set the hardware buffer to 50ms (per BeepExclusive results).
Aaaaahh!
Thank you for the insight.
This looks like a case of a Muppet user here not understanding fully what he's doing / testing or the sophistication of what you're producing.
Trying to follow, even if not fully understanding, what you say, I ran the RME Hammerfall HDSPE settings (which, up to now, I have never had cause to touch) and, perhaps unsurprisingly, so soon as I select a sample rate (under Clock Mode) that matches the file(s) being played, all works perfectly - even up to an admittedly daft 24-177.
I only say in my defence that I may have been misled by the first file that I sampled and reported as working: it was 24-44 and played without apparent error even though the sample rate was still set to a standard 44.1. It's been set as that ever since I installed the card (and its predecessor) and I've never had to adjust the sample rate before through all the various developments in exclusive mode in FB2K that I have followed assiduously.
If you can spare a moment to enlighten me it might prevent me making similar unhelpful errors in the future.
TIA
foobar2000 1.6.7 beta 12
play some mp3 have Problem.
but i use another software can play.
Note that exclusive output - like all output plugins of the sort - doesn't perform any resampling of its own; if your device isn't agreeing with the sample rate of your audio files, errors happen. This is currently the intended behavior.
I'll think of some solution for this for post-1.6.7, perhaps negotiate some optimal rate to resample to.
Thanks Peter for your work on getting this right but I would encourage you NOT to engage some auto-resampling routine to Wasapi exclusive. As you described, passing the file rate straight through to the device is intended behavior. Users with devices that are not compatible with the native sample rates of their files already have several options to handle this via Foobar DSP resampling plugins. IMO, why add an extra layer of handling to something that is proving tricky enough as-is to fix.
Beta 12 has fixed all the issues in exclusive mode with my Fiio K5 Pro.
Note that exclusive output - like all output plugins of the sort - doesn't perform any resampling of its own; if your device isn't agreeing with the sample rate of your audio files, errors happen. This is currently the intended behavior.
I'll think of some solution for this for post-1.6.7, perhaps negotiate some optimal rate to resample to.
Thanks Peter for your work on getting this right but I would encourage you NOT to engage some auto-resampling routine to Wasapi exclusive. As you described, passing the file rate straight through to the device is intended behavior. Users with devices that are not compatible with the native sample rates of their files already have several options to handle this via Foobar DSP resampling plugins. IMO, why add an extra layer of handling to something that is proving tricky enough as-is to fix.
I agree. Beta 12 making music here. Apparently the default buffer size in exclusive is small enough for Xmos 208 USB devices. It took me a long time to figure out the 25 ms default in the component was just a bit too large.
Many Thanks Peter.
foobar2000 1.6.7 beta 12
RAL-DSDHA5, DENON DA-310USB
No Problem. It will be played good
----------
FOSTEX HP-A4, FOSTEX HP-A4BL
The noise is still terrible.
Thanks for confirming.
As for FOSTEX, looks like I'll have to resurrect the advanced preferences option, to set the hardware buffer to 50ms (per BeepExclusive results).
I have a Fostex HP-A8C and when I use exclusive mode with B12 the audio is playing very slowed down. I have tested 44.1/16 and 96/24 and they both behave the same with the music slowed down. I have tested with smooth seeking enabled and disabled without any change.
Note that exclusive output - like all output plugins of the sort - doesn't perform any resampling of its own; if your device isn't agreeing with the sample rate of your audio files, errors happen. This is currently the intended behavior.
I'll think of some solution for this for post-1.6.7, perhaps negotiate some optimal rate to resample to.
With the old WASAPI exclusive mode component, the expected behavior was that exclusive mode would output whatever format it is fed, and it would force the output device into that format, only returning an error if that format isn't supported by the output device. For instance, when you play a 44.1kHz file the output device uses that format, then if the next song is 96kHz it is switched to that format.
Is this no longer the case with the built-in exlcusive mode?
I usually use a resampler anyway, but I did enjoy having a mode that would just output the file as is and force the output device to adjust for each track.
Hi :) A_Man_Eating_Duck
> playing very slowed down
Yes.
No Ploblem
FOSTEX HP-A3, FOSTEX FS-3DA (96/24)
FOSTEX HP-A4, FOSTEX HP-A4BL (192/32)
Terrible noise, Stagnant sound
Hi :) A_Man_Eating_Duck
> playing very slowed down
Yes.
No Ploblem
FOSTEX HP-A3, FOSTEX FS-3DA (96/24)
FOSTEX HP-A4, FOSTEX HP-A4BL (192/32)
Terrible noise, Stagnant sound
Just to add to my report, there is distortion and it sounds underwater while playing back very slowly.
With the old WASAPI exclusive mode component, the expected behavior was that exclusive mode would output whatever format it is fed, and it would force the output device into that format, only returning an error if that format isn't supported by the output device. For instance, when you play a 44.1kHz file the output device uses that format, then if the next song is 96kHz it is switched to that format.
Is this no longer the case with the built-in exlcusive mode?
I usually use a resampler anyway, but I did enjoy having a mode that would just output the file as is and force the output device to adjust for each track.
I think Peter intends the built-in exclusive to function as you describe, which after all is what the definition of wasapi exclusive is, but from his last post it sounded like he was considering the possibility of adding functionality that in case of the sample rate not being device supported would automatically resample to a supported rate, instead of returning an error message. As a matter of fact, this is indeed what BASS library-based players do that incorporate bass.dll/basswasapi.dll for exclusive mode--fallback to a supported rate if the actual is rejected by the device.
Me, I prefer an error message. Then I have the option to add the DSP resampler plugin I choose, setup as I choose, to resample the rates not supported by my own device.
Me, I prefer an error message. Then I have the option to add the DSP resampler plugin I choose, setup as I choose, to resample the rates not supported by my own device.
This.
If the bit perfect is the objetive, then do not add anything to the path, but, when the sr diferences comes, there is always a dedicated Resampler on the DSP, and when the sr source is the same as the sr hardware, theres not loss in the path in that case.
With the old WASAPI exclusive mode component, the expected behavior was that exclusive mode would output whatever format it is fed, and it would force the output device into that format, only returning an error if that format isn't supported by the output device. For instance, when you play a 44.1kHz file the output device uses that format, then if the next song is 96kHz it is switched to that format.
Is this no longer the case with the built-in exlcusive mode?
I usually use a resampler anyway, but I did enjoy having a mode that would just output the file as is and force the output device to adjust for each track.
No implicit resampling is done with exclusive mode; unsupported sample rates fail to play.
Realtek ALC662, driver version: 6.0.1.8036 (2.81). Trying to play 5.1 24-bit track in 1.6.7 beta 12.
foo_out_wasapi: 5.1 track is played. All channels are audible if "5.1" is set in Realtek HD Audio Manager, and only two channels are audible if "Stereo" is set.
Built-in exclusive: Unrecoverable playback error: Unsupported stream format: 44100 Hz / 24-bit / 6 channels (0x3F).
foobar2000 1.6.7 beta 12
play some mp3 have Problem.
but i use another software can play.
How is anyone supposed to respond to this?
I wonder how many users in this forum have an idea of what is exclusive mode and how it is work.
In exclusive mode there's not tolerance on different sample rate and bitdeph is the most abstract layer in audio on windows.
So, when any app is configured for exclusive mode that means there's not space for another app to stream (hence the name 'exclusive').
Some apps like ASIO4All take advantages of this for more compatibility on certain audio apps like DAW's, Plugin Host's, Editors, Instruments, etc...
But, here in Foobar2000, the output is very specific to the format used. (and nothing to do with the codec). It's about the communication between App and Device, to deliver the most untouched sound possible.
I don't know if I'm clear enough.
Beta 13.
5.1 not playing regression = fixed.
Special fix for FOSTEX devices added, please test. Default settings should be OK on these now; if they aren't, you can override the buffer length to find a working value.
> Special fix for FOSTEX devices added
Amazing! Many Thanks Peter.
Beta 13 making music here. Maybe it's ready...
I've just tested my Fostex HP-A8c with Beta 13.
44.1/16 - works.
96/24 - works.
192/32 - works.
Thank you for all your hard work in figuring it out especially for us Fostex users.
May i ask what was the special fix needed for the Fostex devices?
Thanks for testing and confirming.
I made my code check for FOSTEX in device name and use 50ms buffer instead of querying the system default - which seems to be 10ms everywhere and doesn't work with FOSTEX.
Since the above logic may turn out to be faulty, you can manually override the number.
I can't default to 50ms for everyone because that breaks with other cards instead.
I tried to dig up something similar to FOSTEX from my pile of devices, with no luck; even old M-Audio Young works without glitches, so it seems to be an issue isolated to one vendor so far.
If you find another soundcard having similar issues, please let me know so I can investigate.
I know this sounds hacky, but it's really harmless compared to, say, FiiO hacks that I have in my Android code.
Was using 1.6.7 beta 1. Update to 1.6.7 beta 13. Exclusive mode was working fine. Now I get:
Unrecoverable playback error: Unsupported stream format: 88200 Hz / 24-bit / 8 channels (0xFF)
The format is ok, and 8 channels to my DAC always worked (I use a software X-over in foobar). When I choose WASAPI normal mode, I have no problems. If I reinstall the 'now obsolete' Wasapi exclusive component, all works fine as well. ASIO works as well. - Beepexclusive works.
I'm afraid to reinstall the previous version, as this may override the X-over settings I toiled on for so long....
I use an XMOS USB dac, using the USB 2 audio protocol.
Whilst, by manual selection, I can get Exclusive mode in Beta 13 to produce sound at all bit rates and frequencies it is all hugely distorted - even at 16-44.1 - and whatever the output device. I have never encountered that before (and have never had to select frequency manually).
Perhaps unsurprisingly, normal mode works without problem and without manual selection at any bit rate or frequency, so does ASIO, to which I have reverted.
RME Hammerfall HDSPE AIO Pro on Win10 x64, analogue output to 'speakers, dedicated headphone outlet (Shure SRH1540).
That RME DAC sounds like it's another special case for buffer duration, that Windows itself probably deals with, but exclusive mode leaves it to the app developer to figure this out. Check out Advanced Preferences, search for the buffering setting and maybe experiment. The other DAC series that needed a special override needed 50ms instead of the system default of 10ms.
Which mode does the built in exclusive mode (1.6.7 beta 13+) use, Event or Push? Just curious.
Which mode does the built in exclusive mode (1.6.7 beta 13+) use, Event or Push? Just curious.
Which is the better?
Which is the better?
No real "better;" Event has the lowest latency, but the audio quality of both modes is identical. Some devices/DACs do not support Event.
That RME DAC sounds like it's another special case for buffer duration, that Windows itself probably deals with, but exclusive mode leaves it to the app developer to figure this out. Check out Advanced Preferences, search for the buffering setting and maybe experiment. The other DAC series that needed a special override needed 50ms instead of the system default of 10ms.
Thank you. Setting it to 50ms solves the problem.
However, can you bear to educate me a little further?
As others have noted, previous iterations of Exclusive mode (earlier betas or earlier components) did not require the sample rate or bit depth to be set manually: they played without user intervention.
Whilst I follow at (at a basic level of understanding) the point made by Fabcore above, I don't understand the reasons for the (apparently) changed behaviour. I have tried to learn and follow the received knowledge on this site to use an output method likely to produce the most accurate reproduction but, from a user/listening perspective, having to make regular system alterations to take account of varying sample rates and bit depths is, I confess, a deterrent. Whilst the vast majority of my music is standard Red Book FLAC, some of it is 24-88 and 24-96 and its a pain to have to make adjustments during the running of a play list.
That's why, despite Peter's advice on the component page about the use of ASIO, I have currently reverted to using it on the RME card. Until I had begun to try and follow the Exclusive mode development I had used RME ASIO for 10 years or more without any problem.
If, to get round the practical usability problems that I describe, I continue to use the RME ASIO driver, what am I missing (and failing to understand)?
TIA
Was using 1.6.7 beta 1. Update to 1.6.7 beta 13. Exclusive mode was working fine. Now I get:
Unrecoverable playback error: Unsupported stream format: 88200 Hz / 24-bit / 8 channels (0xFF)
The format is ok, and 8 channels to my DAC always worked (I use a software X-over in foobar). When I choose WASAPI normal mode, I have no problems. If I reinstall the 'now obsolete' Wasapi exclusive component, all works fine as well. ASIO works as well. - Beepexclusive works.
I'm afraid to reinstall the previous version, as this may override the X-over settings I toiled on for so long....
I use an XMOS USB dac, using the USB 2 audio protocol.
Does anyone know if installing an older version will overwrite my DSP and theme settings? When I try, it warns that it will overwrite certain settings.... So I have not done that yet.
That RME DAC sounds like it's another special case for buffer duration, that Windows itself probably deals with, but exclusive mode leaves it to the app developer to figure this out. Check out Advanced Preferences, search for the buffering setting and maybe experiment. The other DAC series that needed a special override needed 50ms instead of the system default of 10ms.
Thank you. Setting it to 50ms solves the problem.
However, can you bear to educate me a little further?
As others have noted, previous iterations of Exclusive mode (earlier betas or earlier components) did not require the sample rate or bit depth to be set manually: they played without user intervention.
Whilst I follow at (at a basic level of understanding) the point made by Fabcore above, I don't understand the reasons for the (apparently) changed behaviour. I have tried to learn and follow the received knowledge on this site to use an output method likely to produce the most accurate reproduction but, from a user/listening perspective, having to make regular system alterations to take account of varying sample rates and bit depths is, I confess, a deterrent. Whilst the vast majority of my music is standard Red Book FLAC, some of it is 24-88 and 24-96 and its a pain to have to make adjustments during the running of a play list.
That's why, despite Peter's advice on the component page about the use of ASIO, I have currently reverted to using it on the RME card. Until I had begun to try and follow the Exclusive mode development I had used RME ASIO for 10 years or more without any problem.
If, to get round the practical usability problems that I describe, I continue to use the RME ASIO driver, what am I missing (and failing to understand)?
TIA
If the RME ASIO driver has worked for you for 10 years you should keep using it and not worry about buggy ASIO drivers because obviously the RME driver works for you.
As others have noted, previous iterations of Exclusive mode (earlier betas or earlier components) did not require the sample rate or bit depth to be set manually: they played without user intervention.
Even with the old WASAPI exclusive mode plugin, you still had to set your system's maximum supported bit depth/data format. Also, I just checked and the built-in exclusive mode does indeed output the music as is, and I get an error trying to play 22.05kHz tracks unless I enable a resampler in my DSP. Behavior seems to be the same as the old plugin now.
Beta 14 playing music here.
Was using 1.6.7 beta 1. Update to 1.6.7 beta 13. Exclusive mode was working fine. Now I get:
Unrecoverable playback error: Unsupported stream format: 88200 Hz / 24-bit / 8 channels (0xFF)
The format is ok, and 8 channels to my DAC always worked (I use a software X-over in foobar). When I choose WASAPI normal mode, I have no problems. If I reinstall the 'now obsolete' Wasapi exclusive component, all works fine as well. ASIO works as well. - Beepexclusive works.
I'm afraid to reinstall the previous version, as this may override the X-over settings I toiled on for so long....
I use an XMOS USB dac, using the USB 2 audio protocol.
Does anyone know if installing an older version will overwrite my DSP and theme settings? When I try, it warns that it will overwrite certain settings.... So I have not done that yet.
reinstalled beta 2, playing 8 channels with buikt in exclusive, 88.2K fs
strange....
Not so strange meooms. WASAPI exclusive code was completely rewritten in beta 7, I recall.
Beta 13 and 14 work great here! Schiit Modius DAC.
I'm still curious as to whether it is using Event or Push, but I suppose it doesn't really matter since it's working. I mostly want to know because my DAC didn't work well with Event before and I'd be pleasantly surprised if the built-in exclusive mode is using Event and it's somehow working now.
Exclusive was working fine in beta 13 with my Chord Qutest DAC, but beta 14 fails to play with all files (any bit rate or resolution), giving me a "Unrecoverable playback error: Waiting for hardware timed out". Switching back to default (shared) mode plays without issues.
Exclusive was working fine in beta 13 with my Chord Qutest DAC, but beta 14 fails to play with all files (any bit rate or resolution), giving me a "Unrecoverable playback error: Waiting for hardware timed out". Switching back to default (shared) mode plays without issues.
Try the buffer value of 50ms
Tried buffer set at 20, 50, 80, no difference. At 100 ms, I get a stuttering output, which just gets worse at any higher setting.
Okay, please stick with beta 13, I'll revert the change as it apparently causes more trouble than benefit.
https://www.foobar2000.org/getfile/foobar2000_v1.6.7_beta_13.exe
Does anyone know if installing an older version will overwrite my DSP and theme settings? When I try, it warns that it will overwrite certain settings.... So I have not done that yet.
The worst that can happen is loss of settings that were introduced in the newer version you're reverting from. Not of something that the old version understand.
Not so strange meooms. WASAPI exclusive code was completely rewritten in beta 7, I recall.
I mean, it's strange that beta 13 does not work here, but beta 2 does work.
I mean, it's strange that beta 13 does not work here, but beta 2 does work.
But it's not? Beta 2 and 13 have two different implementations, hence they might have different bugs =)
Thanks, Peter. Exclusive is working for me again in beta 15, with the default buffer setting.
Foobar2000 1.6.7 Beta 9
Win 10 Build 21390.2025
(voicemeeter potato 3.0.1.8 ) / Komplete audio 1, ASIO
Hi I just wanted to report that I got 'pulsating' sound when in exclusive mode, sound is fine when not in exclusive mode.
Beta 15 works fine for me with exclusive mode! :)
Beta 15
Playing typical mp3 via Remote Audio [exclusive] (RDP)
Unrecoverable playback error: Unsupported stream format: 44100 Hz / 16-bit / 2 channels (0x3)
Without exclusive playing fine.
If you're using foobar via RDP and trying to use exclusive mode, I'm pretty sure it's not supposed to work. Or rather it's not supposed to work if you expect to hear the sound on the local machine.
If you're using foobar via RDP and trying to use exclusive mode, I'm pretty sure it's not supposed to work. Or rather it's not supposed to work if you expect to hear the sound on the local machine.
In this case the exclusive mode should not be displayed in the output list.
You can playback on the remote machine using exclusive mode if you configure the rdp client accordingly. Even if that's not your use case, for some people it might be. So I don't see a reason to blend it out and if you think a little about what it technically does the behavior is quite logical.
Beta 15 doesn't work with Dr DAC 2 DX on windows 7. Error "Buffer too large". Tried different buffer values: 10,20,30,40,50,60,70,80,90,100,200 with no success. Betas 13 and 14 were OK.
I've just been testing Beta 15 and I've found a weird bug when switching between 2 outputs when using exclusive mode.
If i start playing a track using the Realtek HDA (exclusive) and then use the output switcher in the toolbar to change to my Fostex the playback can get stuck in a loop. I don't hear any audio from my Fostex in this looping state. While it's stuck looping i can use the output switcher to change back to the Realtek HDA and playback will continue like normal.
This doesn't happen every time when I switch between the Realtek and Fostex but i have managed to trigger it about 10 times in 5 mins.
EDIT: Tested with Beta 13 and i can't reproduce the problem.
You can playback on the remote machine using exclusive mode if you configure the rdp client accordingly.
and how I must configure it?
In the settings of the official Microsoft Remote Desktop client for macOS I can configure on which device audio will be output. I don't know how to do it in other clients.
The Windows client allows you to play sound on a remote or local machine, it allows you to play sound in exclusive mode, but not on the remote machine.
Exactly. And as foobar2000 has no way to detect a) that you use it via rdp and b) how you configured the rdp connection, this is not foobar2000's problem. I actually don't see a problem in the first place as all points that make exclusive mode useful don't apply via rdp. Conclusion: Just don't try to use it via rdp.
Beta 16 playing music now. It works with event checked and unchecked using default buffer sizes. Fading is on. It's probably best to have options because there is a lot of hardware out there. Some of it is old or strange. As compared to the component WASAPI, the default buffer size did not work for me in event mode and I have a very widely used Xmos 208 USB interface DAC. That's a real improvement in terms of eliminating user frustration.
Peter, you are very patient. Have a nice weekend and a long one if you are in the US.