INVALID ARG with 705.6kHz WASAPI

[numlog]

''INVALID ARG device can not play'' error pops up when trying to play any file at 705.6kHz with WASAPI, i though it was WASAPI limited to 352.8kHz but Jriver MC will upsample and play at 705.6 with WASAPI. also 768kHz does work in XXHE and it sounds great.
what could the problem be with 705.6?

[PeterSt]

Hi Numlog,

Can you switch on logging (at the bottom in Settings), kill XXEngine3.exe (click blue led in the right hand border), press Play on that file, let the error appear on screen, do nothing further and now grab tha latest X3 and X3PB two log iles. You can attach them on a post in response.

Btw, I am not 768KHz will work in XXHighEnd by other DAC's than the NOS1. So maybe recheck if that really works, because I have doubts about it (and then the general issue is that it was never made for normal DACs doing 705.6/768 - which in the not so far past just did not exist).

Peter

[listening]

Btw, I am not 768KHz will work in XXHighEnd by other DAC's than the NOS1.

Hi Peter,

705.6 and 768 KHz are working with the SMSL DAC.

Georg

[PeterSt]

Thank you Georg. I don't think I was ever able to test that (the NOS1 uses a special connection to achieve that sampling rate).

Best regards,
Peter

[numlog]

files attached.

768 is working after testing with a few different 48 and 96kHz files

btw this is with Topping D50, using DIYinHK USB to IS2 interface.

[PeterSt]

Is it possible that you send me that track (via FileMail etc.) ?
I don't think it is the track, but I need to be sure. And then I compare the logging with what happens over here.

[numlog]

I have tried many different tracks, wav, flac, mp3, 88.2kHz, some stored on different drives, nothing works. this was just most recent track in playlist.

It might actually be this USB interface im using https://www.diyinhk.com/shop/audio-kits/107-xmos-dsd-dxd-768khz-high-quality-usb-to-i2sdsd-pcb.html, if you scroll down they list all supported ''I2S signal specification'' but 705.6 is not included, yet the other 44.1 multiples are.

obviously 705.6 is supported in some capacity, it works with KS mode, ASIO and even with WASAPI in JRiver... and the DAC's displays indicates 705.6kHz  in all these cases.

Maybe this is some raw form of WASAPI support which XXHE uses for optimum SQ?

[PeterSt]

Maybe this is some raw form of WASAPI support which XXHE uses for optimum SQ?

Although this would be true (like "Event Mode" or whatever other software calls it) is not in there at all. It is just (indeed) that mere raw mode which existed only at the very beginning of WASAPI. But that should not matter.
What does matter is the denotation of DIYinHK at the driver, which tells that using the highest speed is at your own "risk" etc. or whatever it tells or ever back told about it (maybe this changed). So this is (or was ?) some self-implementation of the IIRC XMOS driver and it is tweaked or tricked. So yeah ... maybe that is it.

On an other note, be aware that not all software implements WASAPI in Exclusive Mode (and IIRC JR does not or at least allows the situation of "not"). This means that resampling may take place if a sampling rate is not supported.
If Foobar did not change things, then that would be the better candidate for comparing because Foobar does not (did not) allow working outside of Exclusive Mode (same for XXHighEnd and that thus can incur for the culprit easily).

Please be aware that Q1 is quite crucial for WASAPI to work (and that the error in particular indeed can come from this). At getting it to work, always have xQ1 at 1 and best is to have the Device Buffer Size at its default of 4096. The default of Q1 is 14 (so start there) and vary it with 7 and 20 (not everything between it). If this does not help, set the Device Buffer Size to 1024 and try the 3 Q1 settings again.
If that again does not help, set back the Device Buffer Size to 4096 and never look at it again (it probably does nothing these days, except for being part of the calculation which Q1 x xQ1 also is part of (think like Q1 x x Q1 x DevBufSize).

For WASAPI this is all about timing and how the endpoint device (DAC) talks back about this. So if that does not happen for this particular rate ...

On a not unimportant side note : I can't see per the logging where it realy goes wrong or what part of the code is executed. Maybe this is because it has been 100 years by now that I used WASAPI - maybe this is because I removed redundant code. But the fault and abrubt ending in the log file I don't recognize.
Btw, it should be so that you get one or two more error messages, one of them showing a sequence of numbers. Am I right ? if so, can you give me a screencopy of that ?

Peter

[numlog]

foobar resampler doesnt support 705.6 so no other way to test it. there exists some 768kHz audio test file online but no 705.6.
you are correct about number error, screenshot is attached.

A future driver or firmware update for interface could fix the problem, thats the best i can hope for.

[listening]

Hi Numlog,

did you try https://sourceforge.net/projects/resamplerv/ ?

Georg

[numlog]

I hadnt, thanks. its not working, so that answers that 

[charliemb]

''INVALID ARG device can not play'' error pops up when trying to play any file at 705.6kHz with WASAPI, i though it was WASAPI limited to 352.8kHz but Jriver MC will upsample and play at 705.6 with WASAPI. also 768kHz does work in XXHE and it sounds great.
what could the problem be with 705.6?

I'm having a similar problem with the Holo Spring 2 DAC.  768 (16x) works with 46, 96, etc. source material but 705 does not. 

Has anyone had any luck running XXHighEnd with the Holo at 705K?

Much appreciated. 

Thanks,
Charlie

[charliemb]

Hi Peter

Notice that I changed the subject line to better reflect the problem.

It could have taken years to stumbling into this nugget of gold, but last night I was lucky to open my eyes and read 705K displaying on my DAC.  I had to confirm that in fact I was using XXHE.  I was.  How can this be?

Well it turns out I was playing a Pretenders album.  This album starts with 96/24 material, but at about track 6 and onwards, the tracks become 44.1/16.  Well,  XX happily played the 96/24 of course and when it came to the 44/16 is just kept on playing without problem.   Unattended.  I've not checked attended just yet.

Another way of saying this, it appears, is that XXHighend.exe can't play 705, but XXEngine3.exe can.

As it appears, w/ WASAPI, XXHE plays 705.6 and 768 no problem, unless a 44.1KHz source is first in the list of tracks to be played.

I presume this will work for anyone: 

• Choose WASAPI as the driver
• Create a playlist with the first track a 96/24 track
• Add 44.1/16 tracks after that track
• Click play in unattended
• Enjoy 705 material

So clearly this is not about the stream or its compatibility.  Instead, initialization?  handshaking?

I will try a few more iterations today.

Thanks,

Charlie

[Edit]  In case it matters, I was using the 2nd Custom Filter listed under [F], the 705/768 High filter

[PeterSt]

Charlie, interesting ...
The problem is that someone like me can always play 705.5 or 768, regardless. So ...

If you have more data, I will be happy to read about it.
Thanks !
Peter

[charliemb]

Additional data:

If I load a 96/24 track first, then 44.1 tracks after that and hit play, then after unattended starts playing if I hit Alt-N, xxEngine3 moves to the 44.1 track and plays it okay at 705K.

If I try the same in attended mode, clicking on Next I get the "INVALIDARG" message and it doesn't play at all.