Author
Topic: Configure ASIO Buffer Size (Read 11127 times)

Is there a way to configure the ASIO buffer size the XMPlay ASIO 7a plugin uses? If not, would it be feasible to provide one?

Some background...

I understand that if Options and stuff->Output->ASIO->"Always use the preferred driver buffer size" is checked, XMPlay will not set the buffer size, and leave it up to the device ASIO driver. If unchecked, "the ASIO plugin may override the driver's buffer size with something that it thinks is more appropriate" (from the thread "Output Buffer"). So, I'm talking about the unchecked behavior here.

From the thread "Strange behavior with Creative ASIO," I see Ian says something more appropriate is "the XMPlay ASIO plugin will default to using 50ms buffers".

He says "default to using 50ms" - is there a way to override that default? There isn't a setting in the GUI of course, and I don't see anything in the "Secret Settings" of xmplay.ini for ASIO buffer size.

Side question, 50ms of *what*? 44.1 KHz 16 bit, or 192 KHz 32 bit, or What is the size of the buffer in bytes?

More background...

I am outputting to an ASUS Xonar Essence One, which uses a modified C-Media Universal ASIO Driver. My understanding is this driver sets its default buffer size to 2048 bytes. This driver is pretty lame (like a lot of ASUS drivers) and provides no control panel setting to adjust its buffer size, and I can't find any setting in its ini file or registry to set it either. I always output in 32 bits (I use the DSP), so with typical 44.1 KHz audio that's only about 11 ms.

I have an issue on my system with a high DPC latency spike of from 60 ms to 95 ms (yeah that's a killer) that hits around every 3-5 minutes. I actually had another DPC latency spike that hit every 4 seconds, but I was able to resolve that with a network card driver update. This remaining one, however, is really nasty to debug (it's also coming through the NDIS driver, but it's very difficult to figure out via the stack trace what's triggering it - I may not be able to solve this one).

Anyway, as you can image, a 90 ms spike causes quite a glitch in the audio, especially with the device driver's little 11 ms buffer.

Maybe I'm kidding myself, and the latency spikes from the network drivers will still interrupt the ASIO USB output, but I'm hoping a larger ASIO buffer setting can keep it going while the network driver does its worst.

Letting XMPlay's ASIO plugin set the buffer size seems to help a little. I think it's perhaps because some of the latency spikes are under what the buffer covers, or the larger buffer helps cause less of a glitch? But it still glitches. I'm OCD about the music, so these glitches drive me nuts!

There ya go, any suggestions or perhaps a little mod to provide a GUI or ini file setting for the ASIO plugin's buffer setting would be very much appreciated!

Side question, 50ms of *what*? 44.1 KHz 16 bit, or 192 KHz 32 bit, or What is the size of the buffer in bytes?

50ms are 50ms, no matter what sample format. That's what milliseconds are about. They always are the same time, but not necessarily the same amount of samples. If you need to translate that into samples, multiply 50 by 44100 (or whatever your sampling rate is) and divide it by 1000. And if you want to have the result in bytes (which is pointless), multiply by the number of channels and sampling point size (that would be 4 for 32 bit floating point) - however, ASIO buffer lengths are measured in samples, not bytes.

However, the way I understand the problem, Ian couldn't change much here - I understand that leaving this checkbox unchecked means that XMPlay first tries to set the desired buffer size (i.e. the size you have configured), and if that fails, it will fall back to trying 50ms. But: since you already say that the ASIO driver always uses a default buffer size of 2048 samples, XMPlay will have to use this buffer length anyway! You cannot simply use a different buffer size than what the ASIO driver accepts, since then it won't do anything!

Yes, I understand what a ms is, thank you. I wasn't understanding the buffer size to be samples, however, I thought it was bytes.

But as you point out, 50 ms can be a variable number of samples depending on the sample rate. If I have 3 songs queued up, one at 44.1/16, one at 96/24, and one at 192/32, does XMPlay do an ASIODisposeBuffers() and ASIOCreateBuffers() before playing each song to make the buffer be 50 ms worth of samples for each song? I don't understand coding to the ASIO driver interface, but I would guess ASIOSetSampleRate() has to be called before each song as well, perhaps even the whole driver needs to be re-initialized?

My understanding is that an ASIO driver has a preferred buffer size. In many drivers, that preferred size can be configured via a control panel for the driver, or via ini settings for the driver. The C-Media driver ASUS uses is lame and doesn't have that - the preferred buffer size is hard coded within the driver to 2048 samples. Maybe I should try a different ASIO driver, but I don't know if they're interchangeable (it's via USB to the Xonar)?

But that doesn't mean that's the only size the driver supports - it's just the preferred size. Many drivers support a range of buffer sizes. ASIOGetBufferSize() queries the driver for what it supports (min, max, preferred). I really don't know what the C-Media ASIO driver actually supports - I think I would have to code something up to experiment and I'm not sure I could pull that off at this point.

I don't understand what you mean by "XMPlay first tries to set the desired buffer size (i.e. the size you have configured)"? I have not been able to find any way to configure the ASIO buffer size used by XMPlay's ASIO plugin. In the forum threads I referenced in my first post, I believe Ian specifically says it is 1) not configurable, and 2) not the same as the Buffer setting on Options->Output, and 3) the desired buffer size is hard-coded by XMPlay at 50 ms worth of samples. If I'm mistaken and there is a place to configure the ASIO buffer size, please let me know where it is.

I still believe there are various ways to implement something that can provide user configurable ASIO buffer sizes. For example, if "Always use the preferred driver buffer size" is unchecked, XMPlay could query the supported buffer sizes via ASIOGetBufferSize() and enable & fill a pull-down to select from. Or if the user buffer size is allowed to be a free-form numeric entry, or read from xmplay.ini, XMPlay could use the nearest driver-supported size (next larger up to max). This would allow drivers of all capabilities to be used, and allow the user to increase the buffer size for situations like mine.

Anyway, there ya go. I wouldn't be surprised if I'm missing or misunderstanding something, but that's what I'm currently thinking.

If the buffer size is hardcoded in the drivers, that's where the problem is.Any audio player (not only XMPlay) will have to use that buffer.If the driver doesn't provide the ability to configure the buffer lenght... you can't configure it.HINT: try asio4all, and see if it performs better? (I think it doesn't makes sense since you bought a Xonar Essence One, but trying costs nothing)QUESTION: are you sure the Xonar Essence One -CAN- accept different buffer lenght than the hardcoded values? (i.e. there's a HW limit too)

It's the *preferred* buffer size that's hard-coded. That's just the preferred (suggested) size. An application *does not* have to use the preferred buffer size, it can set a different buffer size when it sets up the driver, by using the ASIO.CreateBuffers() call.

Just because the driver doesn't provide a way to configure the preferred buffer size doesn't mean the application can't set a different supported buffer size at run time.

I don't know what the supported min and max buffer sizes are for the C-Media driver. Maybe it only supports 2048 samples, maybe not. I looked for docs for it with no luck. The only way I can think of to find out is the write some code that makes a ASIO.GetBufferSize() call to see what the returned range of supported sizes is.

The ASIO driver connects to the Xonar via USB. So perhaps there is only so much data that can get queued up in a way that the USB interface can continue to pump it out even when the NDIS driver goes wild and hogs kernel mode for 90+ ms. I'd just really like to see if I can work around this somehow (and there are lots of people with this problem, Google for "DPC latency problem").

I had tried ASIO4All, but the slider on its control panel only supports a 2048 sample buffer maximum and I didn't see a way to set it larger otherwise (like in an ini file). It has the interesting kernel buffer setting that I didn't mess with last time I tried it, so maybe that could help as well? There was a reason I uninstalled it - it was a while ago but I think it didn't support the "bit perfect" feature on the Xonar. I'd have to see if that really matters, but I guess I thought it did at the time. I can give it another go.

If anyone knows of an ASIO driver that would work with a USB device and supports a buffer size up to 5120 samples, please let me know.

To clarify what happens regarding ASIO buffers... When "Always use preferred driver buffer size" is enabled, the driver's preferred buffer size will be used. Otherwise, the lowest of the following will be used: the driver's maximum buffer size, 1/5th of the buffer requested in the "Output" options, 50ms. Once the ASIO buffer size is set, the total buffer size requested in the "Output" options is rounded down to a whole number of ASIO buffers.

If you would like to try changing the 50ms value to something else, here's an update that adds an XMPLAY.INI option for that...

Add a "Buffer=x" line in the "[ASIO]" section, where "x" is in milliseconds. Note that the buffer set in the "Output" options should be at least 5x "x" due to the "1/5th" thing.

Regarding what happens when files with different sample rates are played (and "Apply sample rate to all file formats" isn't enabled), the output is reinitialized whenever the sample rate (or channel count) needs to change. That applies to all output systems, not only ASIO.

If you would like to try changing the 50ms value to something else, here's an update that adds an XMPLAY.INI option for that...

Thank you, Ian, you rock! I was hoping it would be a relatively easy code change for you to make.

Is there any way to tell what the buffer size actually got set to? Any verbose logging I can turn on or anything? I'll know what the 1/5 output buffer size and the [ASIO] Buffer=x size are setting, but I have no way to know what the driver max is (hopefully bigger than the preferred size of 2048).

I know I may be tilting at windmills here, and may not be able to work around my DPC latency spikes like this, but at least I can try. In fact, I'm going to download now, set Buffer=100 and see if a 90 ms spike interrupts playback again or not.

Grrr... A 64975 us DPC latency spike still causes an audio glitch with Output buffer at 5s and [ASIO] Buffer=116 (should be 5120 buffer size at 44.1). And most spikes are actually larger (75 to 95 ms).

So, I guess either 1) the max buffer size of the C-Media driver is less than 2867+ samples (44.1 for 65 ms, if I have the math right?); or 2) the ASIO buffer size can't protect against this type of latency spike from the NDIS driver.

I notice in the ASIO docs that most drivers support buffer sizes in powers of 2, so 5120 might not be feasible (perhaps I should try for 8192 = 186 ms)? Does XMPlay round to the granularity the driver wants? But even if the size fell back to 4096, that should have covered the 65 ms (92 ms), unless it rejects improper sizes or falls back to the preferred size. Need to play around more...

If anyone knows how to tweak this in any other way (like perhaps settings that elevate the audio priority over the NDIS driver), please let me know. I'm already running XMPlay using MMCSS Pro Audio with elevated priority settings (Scheduling Category = High). But I'm suspecting that the NDIS driver just takes over the kernel and nothing else is going to get any CPU while that's happening.

I've been hunting around for a little utility that can query an ASIO driver and show all its settings (like the min, max, preferred buffer sizes, granularity), but all I've found so far are projects with code that needs to be built, and I don't have a development environment with Visual Studio set up right now to build them.

If anyone knows of such a utility (distributed as a Windows exe), please let me know.

I found an ASIO latency test utility from a company called CEntrance ( http://centrance.com/downloads/ltu/ ). Still looking for a more specific ASIO driver info display utility.

I don't care about testing the latency since I'm only doing playback, but it kinda shows me some driver info (I think).

I think it's querying the driver, and then loading up the Buffer Size and Sample Rate pull downs with that info (but I can't be positive about that).

If that's true, then the C-Media driver seems to have a min=4, max=15300, and granularity=64.

If I ask XMPlay for a 100 ms buffer, that math works out to 4410 samples. Does XMPlay adjust to 4356 or 4420 to match the min + granularity, or just ask for 4410?

I don't know if the driver requires an exact matching buffer size. In other words, based on the granularity and min, it would accept a value of 4420 samples, but what about 4410? Would it adjust to the a nearest valid value (up or down), or fall back to the preferred, or return an error? I'll try to check in the ASIO spec if there is a defined behavior for this, but I guess no guarantees the driver honors that.

Also, BTW, I downloaded the Steinberg ASIO SDK and the C-Media driver looks very much like the reference driver in there (same control panel), so maybe it's a pretty straight copy of it just modified for the Xonar specific functionality (like bit perfect).

If this is not something you want to deal with, just say so. But I'm hoping it could enhance the driver for other people's situations as well.

a. Are you using a laptop? I ask because if you're using a desktop it may be simpler to get a cheap (compared to the xonar) audio card with spdif out, instead of insisting on going usb.(USB audio has a lot of other issues, whatever asus tells you)

b. I think I don't get what's all of this about. I mean, you use ASIO to get bit perfect output, but since for music listening latency is not determinating, you could try to set it to an high value.(I remember that too low latency causes drops in audio if the box has some non performant parts)

a. Are you using a laptop? I ask because if you're using a desktop it may be simpler to get a cheap (compared to the xonar) audio card with spdif out, instead of insisting on going usb.(USB audio has a lot of other issues, whatever asus tells you)

A laptop. That's the main reason for the USB Xonar. I also want something that can handle up to 192/32 audio, and at the time this was one of the only reasonable options. Yes, the Xonar wasn't cheap, and I'm not inclined to scrap it.

What are the lots of other USB issues are you referring to, specifically?

b. I think I don't get what's all of this about. I mean, you use ASIO to get bit perfect output, but since for music listening latency is not determinating, you could try to set it to an high value.(I remember that too low latency causes drops in audio if the box has some non performant parts)

That's true, the latency of the output is not an issue. I don't care if I hit play and it comes out 2 seconds later. If I was doing pro audio recording I would care, but that's not what I'm doing on this machine.

But that's not the type of latency that's causing the problems. It's the DPC latency that is caused when another driver in the Windows system is handling something in kernel mode, and blocks other drivers from getting their share (as you say "non performant parts"). That latency is something entirely different, which is the time it takes for the other drivers to get a chance again.

The culprit driver is the NDIS (network) driver. But this is a tricky one to figure out exactly what the root cause is, because a lot of things can cause processing to happen in the NDIS driver (lots of things use the network). In my case, the NDIS driver will occasionally take up to 95 ms to do whatever it's doing, which is too long and the ASIO USB audio driver starves for samples and the audio glitches.

The requested mod to XMPlay is not to solve the DPC latency problem, it's to try and make the ASIO driver able to survive and keep playing audio when the NDIS driver goes wonky. I was hoping a larger buffer size would load up more data that could still be pumped out during that time, but I now think when the NDIS driver is running the ASIO USB can't run even if it has enough in it's buffer.

Everything was working flawlessly until our small office network was upgraded from 100 Mbps to gigabit with a new router and switch. Then this started. Research is telling me that firewall software can 1) cause NDIS driver DPC latency because it often hooks in and does things in kernel mode, and 2) it can get upset/confused when the network gets swapped out from under it, so I think I'm going to try uninstalling the security suite to see if that helps (although really, fully uninstalling security software can often be problematic).

At least that's what all I think is happening. I'm sure I have more to learn.

About your issues with network drivers:If the issue started with a change in network, then it's your network chip, or something related to it.Try disabling energy saving for the network card (maybe for usb ports too) in advanced energy management (windows 7 I assume)Something that you may have already tried is changing your network card options in hadware devices.(forcing 100M would be a no-no I think, but disabling stuff like green etherent or any other option that may put more work on it and cause the issue)

Possible HW solutions:I suppose getting a USB/spdif converter won't help, and they are pricy btw.You could try to buy a USB3/RJ45 converter as a last resort if the laptop has a USB3 port, those aren't pricy.(basically moving to a different driver and moving the network load to somewhere else)

About USB issues:Many usb chip used for audio have issues, usually bad drivers / limited or poor performance / quality. Often usb input on DACs just doesn't work. That's why spdif is preferred if possible.Tenor was one of the affected chip maker (if I recall cerrectly they used it on a bunch TEAC).Googling and browsing forums should give you lot of examples.It can be this too, but being you on a laptop I think you're correct assuming it's the laptop.

About latency:I did understand the latency you were talking about is not the asio latency.I was just telling you to try to set the asio latency to a high value, to see is it helps.(in form of less resource used / needed, a blind try basically, but not that blind)

related to this. I have a soundblaster audigy 2 and xmplay show me two devices, asio and asio 2. The ms configurations keep on asio, but never on asio 2, and all time that i boot again xmplay it is reset to 50 ms.

If that's true, then the C-Media driver seems to have a min=4, max=15300, and granularity=64.

If I ask XMPlay for a 100 ms buffer, that math works out to 4410 samples. Does XMPlay adjust to 4356 or 4420 to match the min + granularity, or just ask for 4410?

It would actually be rounded down to 4352 (68x64) in that case, as the ASIO plugin assumes that the minimum buffer size will be a multiple of the granularity. Checking with an Asus Xonar soundcard (not USB) here, I'm seeing very similar numbers to you: min=4, max=15360, granularity=64. In that case, the "max" value isn't on a granularity boundary if starting from 4, but the granularity value appears to be wrong anyway, as the preferred buffer size is practically never on a granularity boundary either (whether starting from 0 or 4). The real granularity seems to be 4, the same as the "min" value. I guess it's probably the same in your case.

Btw, regarding what ASIO buffer size is used by the ASIO plugin, in addition to what I wrote earlier, I forgot to say that it will never be set lower than the driver's preferred size.

About your issues with network drivers:If the issue started with a change in network, then it's your network chip, or something related to it.Try disabling energy saving for the network card (maybe for usb ports too) in advanced energy management (windows 7 I assume)Something that you may have already tried is changing your network card options in hadware devices.(forcing 100M would be a no-no I think, but disabling stuff like green etherent or any other option that may put more work on it and cause the issue)

Thanks for your suggestions!

I'm pretty sure it's not the actual adapter hardware (chip) of either the wired gigabit or wireless controllers. I've ran diagnostics on those, and the symptoms are just not consistent with a problem at the hardware level.

I went through each network driver very carefully, researching and understanding each setting and its possible effects, and configured the drivers as best as I could figure out. Yep, the power settings are often mentioned, because they can cause software higher up in the stack to perform badly when the adapter cycles on/off, and I ended up with all the various power settings disabled for now. But the stack traces I'm seeing are not consistent with the activity in the NDIS driver being triggered bottom-up like this.

The activity is higher up in the stack, in the NDIS driver. It appears to be caused by either something that hooks into that layer directly (which is why the firewall software is a possibility), or by something even further up the stack calling into the NDIS driver. Although I am able to see some information the stack traces of the NDIS driver, other software does not have symbols available so all I see are routines with addresses and it's really difficult to tell what's happening.

Possible HW solutions:I suppose getting a USB/spdif converter won't help, and they are pricy btw.You could try to buy a USB3/RJ45 converter as a last resort if the laptop has a USB3 port, those aren't pricy.(basically moving to a different driver and moving the network load to somewhere else)

About USB issues:Many usb chip used for audio have issues, usually bad drivers / limited or poor performance / quality. Often usb input on DACs just doesn't work. That's why spdif is preferred if possible.Tenor was one of the affected chip maker (if I recall cerrectly they used it on a bunch TEAC).Googling and browsing forums should give you lot of examples.It can be this too, but being you on a laptop I think you're correct assuming it's the laptop.

I really don't think the problem is with the Xonar, the USB controller, the USB device driver, or the ASIO driver.

I read quite a bit about the pros and cons of USB audio when I was researching to buy the Xonar. Sure, any of them can have bad drivers, but the C-Media drivers I'm using don't seem buggy. I don't do any audio recording on the laptop, and the Xonar Essence One is playback only. The big pro of card-based audio playback is that they can sometimes withstand this stuff because they often have hardware buffers on board that the audio circuits access directly, so they can't get interrupted by other software monopolizing the kernel. That's not practical for outboard USB playback.

From everything I've read and understand, if the NDIS driver is going to behave so badly, any USB controller and driver stack is going to get stalled. If anyone knows of a specific USB solution that can withstand something like this, I'd be really interested.

Anyway, I believe the ultimate solution is not with the USB or Xonar, but in the NDIS driver stack.

About latency:I did understand the latency you were talking about is not the asio latency.I was just telling you to try to set the asio latency to a high value, to see is it helps.(in form of less resource used / needed, a blind try basically, but not that blind)

Which is exactly what this whole thread is all about. I wanted to set a bigger ASIO buffer, but XMPlay had a built-in max of 50 ms (I needed more than 95 ms). Ian was gracious enough to make the code change to allow that. I think I've confirmed that the ASIO driver also supports a large enough max buffer size, so even though I'm still testing a little blind I'm pretty sure I'm running with an ASIO buffer that's 241 ms.

But sadly, the problem persists. I think the larger ASIO buffer is still not at the right layer in the stack to withstand the DPC latency spike. The NDIS driver interrupts the ASIO driver, so even with the bigger buffer it's just not executing and the USB driver/controller stalls for data to send out. If there was a buffer in the USB controller itself that could be increased or filled more, then maybe the controller hardware could keep pumping out data when the ASIO driver stops sending. But I suspect the buffer in the USB controller is smaller, and fixed in size, so I don't think I can do anything about that (I can't swap out the controller since it's in a laptop and built-into the main board).

The possibly easiest solution would be to use LAN instead of wifi if it's possible for you, and get rid of all wifi drivers. Wifi drivers are the usual culprit for these issues.

It happens both on the wired gigabit and wireless controllers. It's a little more frequent on the gigabit connection, so actually if I just want to listen to some music without using the network much, I disable the gigabit device.

That's also another clue that makes me think the problem is being caused by something common to both network connections, like the security software.

It would actually be rounded down to 4352 (68x64) in that case, as the ASIO plugin assumes that the minimum buffer size will be a multiple of the granularity. Checking with an Asus Xonar soundcard (not USB) here, I'm seeing very similar numbers to you: min=4, max=15360, granularity=64. In that case, the "max" value isn't on a granularity boundary if starting from 4, but the granularity value appears to be wrong anyway, as the preferred buffer size is practically never on a granularity boundary either (whether starting from 0 or 4). The real granularity seems to be 4, the same as the "min" value. I guess it's probably the same in your case.

I know in the end, the driver does what it does. But I wonder if all drivers behave like this one?

The ASIO spec, while not as specific as I would like, seems to say that the set of supported buffer sizes starts at min, and increases by granularity, up to max. I'm referring to the granularity parameter description:

Usually, the buffer size will be a power of 2; in this case, granularity will hold -1 on return, signaling possible buffer sizes starting from minSize, increased in powers of 2 up to maxSize.In the case of the C-Media driver, I would interpret that to be starting at 4 (min) and increasing by 64 (granularity) up to 15360 (max). That would imply the set of supported buffer sizes should be 4, 68, 132, 196, etc.

Yes, it's odd that the returned max size is 15360, not 15300. FWIW, that CEntrance ASIO latency check utility I mentioned above shows a max size of 15300, which implies they interpret the max value to be min + (n * granularity) <= max.

You didn't mention the preferred size returned from the GetBufferSize call? I had read several places that for the C-Media ASIO driver it was 2048. But that's not on a per-spec supported size, either (should be 2052).

If bufferSize is not supported, or one or more of the bufferInfos elements contain invalid settings, ASE_InvalidMode will be returned....I'm assuming you're not getting any ASE_InvalidMode errors, so I'm still curious what the driver exactly does if it gets passed an "in between" buffer size?

It sort of seems like it ignores granularity completely, allowing any buffer size between min and max?

I don't see anything in the spec to ask the driver what it actually set the buffer size to, so I suppose we have no way of really knowing. I would think it can't silently change the buffer size without causing the host app some grief.

If you're specifying some in-between value, and it doesn't error on CreateBuffers, and then you load up the buffers at that size, and the music plays as expected, I guess it's happy.

You didn't mention the preferred size returned from the GetBufferSize call? I had read several places that for the C-Media ASIO driver it was 2048. But that's not on a per-spec supported size, either (should be 2052).

The driver's preferred buffer size depends on what has been set in the control panel. In some cases (including the Xonar), the control panel setting is in milliseconds, so the buffer size will also depend on the sample rate then.

If bufferSize is not supported, or one or more of the bufferInfos elements contain invalid settings, ASE_InvalidMode will be returned....I'm assuming you're not getting any ASE_InvalidMode errors, so I'm still curious what the driver exactly does if it gets passed an "in between" buffer size?

Yes, if I try forcing the buffer to a non-multiple of 4 on the Xonar, then the driver will reject it, confirming that the granularity is actually 4.

You didn't mention the preferred size returned from the GetBufferSize call? I had read several places that for the C-Media ASIO driver it was 2048. But that's not on a per-spec supported size, either (should be 2052).

The driver's preferred buffer size depends on what has been set in the control panel. In some cases (including the Xonar), the control panel setting is in milliseconds, so the buffer size will also depend on the sample rate then.

Sure, I was just curious what the driver reported back for a given setting. For example 44.1 with a 50 ms setting in the control panel calculates out to 2205, which is neither on the 4 sample granularity, nor does it match what I keep reading about 2048.

I've been getting confused because I was reading about a 2048 sample default preferred buffer size, but I was only seeing a "Latency" setting in the control panel in ms. Now I think I'm finally getting that the Latency setting is really indirectly setting the preferred buffer size, right?

It looks like my driver defaults to 20 ms, which if my math is correct 2048 would be a 102.4 sample rate which makes no sense.

Anyway, it doesn't really matter at this point, I think this is moving into the proverbial dead horse zone.

If bufferSize is not supported, or one or more of the bufferInfos elements contain invalid settings, ASE_InvalidMode will be returned....I'm assuming you're not getting any ASE_InvalidMode errors, so I'm still curious what the driver exactly does if it gets passed an "in between" buffer size?

Yes, if I try forcing the buffer to a non-multiple of 4 on the Xonar, then the driver will reject it, confirming that the granularity is actually 4.

Goes to show you can never trust a driver to implement to the spec. But I guess if I took the driver at its word and used the 4, 68, 132, 196... progression, it would work, I just wouldn't realize it could actually do finer-grained settings than it advertises.

Goes to show you can never trust a driver to implement to the spec. But I guess if I took the driver at its word and used the 4, 68, 132, 196... progression, it would work, I just wouldn't realize it could actually do finer-grained settings than it advertises.

To be fair towards Asus, Steinberg's APIs are always horrible to implement and extremely error-prone, because they are underspecified. This is true for both the ASIO SDK and the VST SDK. And there is no such thing as a driver compliance check as you might get it with Microsoft APIs.

I would think the Xonar driver would return a 32 bit ASIOSampleType in its ASIOChannelInfo, but does XMPlay do anything with that vs. the Resolution setting in the Output panel? If Output->Resolution is set to 32, but the ASIOSampleType is 24 bit, would there be a bit depth change happening under-the-hood in the ASIO output plugin? Would the Info panel then show 24 bit?

Also, another bit of info related to ASIO drivers in general...

Using the ASIO4All ASIO driver (or any other driver that access a USB device through WDM like ASIO2Ks) seems to have a limitation with the Xonar. The Xonar can support up to 196 KHz 32 bit audio, but WDM seems to only support 24 bit max (or at perhaps the Xonar device driver only supports 24 bit through WDM).

One of the advertised benefits of ASUS' "bit perfect" feature is that it will send the audio stream unmodified to the DAC on the device. In this case, the ASUS device driver + ASUS ASIO driver should be sending 32 bit audio through USB to the device.

Why does that matter? I use the DSP on XMPlay for replay gain and mild EQ settings. As I understand it, the DSP outputs at 32 bit, so I output at 32 bits to the "bit perfect" ASIO driver so the output from the DSP is sent allegedly unmodified through to the DAC.

Sure, I was just curious what the driver reported back for a given setting. For example 44.1 with a 50 ms setting in the control panel calculates out to 2205, which is neither on the 4 sample granularity, nor does it match what I keep reading about 2048.

I would think the Xonar driver would return a 32 bit ASIOSampleType in its ASIOChannelInfo, but does XMPlay do anything with that vs. the Resolution setting in the Output panel? If Output->Resolution is set to 32, but the ASIOSampleType is 24 bit, would there be a bit depth change happening under-the-hood in the ASIO output plugin? Would the Info panel then show 24 bit?

An ASIO driver supports a single sample format (eg. 32-bit in your case), so XMPlay will produce output in that format if "Use optimal resolution" is enabled, otherwise the ASIO plugin will pad the user's "Resolution" setting to the driver's format (if the former is lower than the latter).

32-bit data is easier/quicker to deal with than 24-bit, so an ASIO driver may choose to deal with 32-bit data even if it doesn't actually use all 32-bits.