WASAPI in Event mode???

[Jan]

Hi,

currently testing (comparative listening) driving a high quality external USB DAC from MB, toward a high quality HiFi installation. Using WASAPI because DAC does not support ASIO (according to manufacturer for well considered reasons, sic).

Question: does MB support WASAPI in event mode (aka async, not push, not sync, not adaptive)?

Background: current set-up works fine (functionally), but does NOT provide the same quality sound as can be achieved with other players that do clearly support async (event) mode. Those other players clearly show the WASAPI capable USB devices twice, one in push and once in event mode.

MB only shows them once, and does not indicate mode. And from comparative listening it seems that MB uses push (or adaptive) mode. That implies that USB transfer is regulated by the (dismal) PC clock, rather then the optimized clock from the USB DAC. And that difference can (very clearly) be heard on high level HiFi installation. As a true audiophile, that actually eliminates MB as a viable player.

However, should it be possible to engage event mode,  due to its superior functionality on many other aspects, MB would be the go-to player if it provides async mode. So if the answer is currently negative, I will put this in as a request for evolution.

Thanks and kind regards.
Jan

[Alumni]

Have you looked at the ASIO4ALL driver? It's not a perfect solution but it's worked for some people.

[Bee-liever]

The basswasapi.dll that MB uses supports both regular and event mode, but only Steven will be able to say for sure what has been implemented.

[Jan]

Thanks for the replies.

Unfortunately ASIO4ALL will not solve this timing issue (make use of the clock of the external USB DAC).

How could I contact Steve for further information on the WASAPI implementation, eg how come the WASAPI capable devices do not show up in both modes, and which mode has been implemented?

Thanks and kind regards,
Jan Stes

[phred]

How could I contact Steve for further information on the WASAPI implementation, eg how come the WASAPI capable devices do not show up in both modes, and which mode has been implemented?

Steven's time on the forums these days is somewhat limited as he's working on MB v3.  He does drop in every now and again and replies when he has something to offer.  So be patient and perhaps he'll offer up an answer.

[Steven]

MB uses WASAPI exclusive but not the event  style. I am planning to add it at some point later in the year for the reason that it has been reported that WASAPI mode doesnt work with some USB devices and i gather event style can solve the issue.

[Jan]

Thanks Steven for clearing this up. I am now anxiously awaiting this feature  .

Other then your (functional) reasons, may I suggest an additional reason for adding WASAPI in event mode.
The difference in resulting sound quality (on high end HiFi systems) between push and event mode is surprisingly big. This is easily explained: in push mode the USB feed is controlled by the (not very stable) clock of the PC, whereas in event mode the USB become asynchronous, and the feed is controlled by the (often very stable) clock of the external DAC. This reduces jitter in the produced analogue music by factors (rather then fractions).
To put it bluntly: for audiophiles MB is currently not an acceptable player if the high end external DAC does not support ASIO (however great all the other stuff you have produced). And there is competition out there (windows based players) that does support WASAPI in event mode ;-). "Fortunately" it lacks the end-user functionality that MB provides.

As I stated before, with all the other functionality that MB has on board, adding WASAPI in event mode would make MB THE go-to player for any audiophile. It could even be positioned as direct competition of $1000+($2000 or $3000 is no exception) "media streamers" current sold by HiFi manufactures.

[vincent kars]

The difference between push and event style is about who is in charge to send the data to the audio device.

Event based:
- Host tells API that it wants to be informed when it is the appropriate moment to send audio
- Host might prepare some audio in a separate thread so that it is ready when the API asks for it
- API asks host for more audio
- Host sends the prepared buffer if it was ready, or prepares then the buffer and sends it.

Push based:
- Host tells API that it will ask when it is the appropriate moment to send the audio.
- Hosts prepares some audio so that it is ready when the API is ready.
- Hosts asks the API if it is ready.
- If it is not ready, waits some time, and asks again
- When the API replies that it is ready, the host sends the prepared buffer. It might also prepare the buffer at this time and send it.

Event style allows for smaller buffers as the latency is lower.

Obvious  all clocking is done by the PC.
Obvious push or event says nothing about the bus being used.
If it is done over USB you won’t as by magic get asynchronous synchronization the moment one switches to event style. You need a USB receiver at the DAC supporting asynchronous USB to do so.

[Jan]

"If it is done over USB you won’t as by magic get asynchronous synchronization the moment one switches to event style. You need a USB receiver at the DAC supporting asynchronous USB to do so."
==> Indeed!

"Obvious  all clocking is done by the PC."
==>I do not understand the situation in that way. You state yourself: "API asks host for more audio". The way I understand it, is that the clock from the USB DAC is the driving force in the timing of that request. and to me that implies that the presentation f the sample to the DAC is regulated by the very stable DAC clock.

[vincent kars]

Most of the time all communication is asynchronous, be it inside the PC or over a network.
One might argue that adaptive mode  USB or SPDIF (DAC slaved to host) are exceptions to this rule.
The ideal solution is a free running clock driving the DA conversion.
It reads the data from a buffer (inherent to asynchronous).
If the buffer is (almost) drained, a request is send for new data.
Basically there are 2 timed events (well a hell lot more of course)
1 – the clock timing the DA conversion
2 – the clock timing the bus e.g. USB/PCI/etc

Clock “2” is of course the hardware of the PC

[Jan]

Hi,

is WASAPI in Event mode still on the books? If so, is there any indication on when it would become available?

Thanks and kind regards,
Jan.

[Steven]

Support for WASAPI event mode has been added to v3.1
However it might be some weeks before i make v3.1 available

[Jan]

Support for WASAPI event mode has been added to v3.1
However it might be some weeks before i make v3.1 available

Thank you, Steven! Now eagerly looking forward to the availability of 3.1. Will provide feed on listening evaluation on high quality HiFi after some extended listening.

[Pietercape]

  Too bad that the Wasapi problems have not been addressed yet. I am keenly awaiting V3.1. I love MB especially the UI but playback of my library is still a problem with pops/click and now amount of experimentation with buffers work. This has long been a non-issue in Foobar and Media Monkey and I wonder why this is such a problem in MB. After an absence of a year I keep coming back to check and was full of hope when V3.0 and the subsequent patch arrived but no luck!
PLEASE Steven !

[SuperMagicom]

I am also waiting/hoping for this.  Currently using my AudioQuest Dragonfly with MB via ASIO4All until 3.1 comes out.