Hi guys.
So I programmed the AHI device interface to play a 16 bit stereo sound. Of about 500KB in length. I found it ended too quickly. I enabled debug output. The device writes were truncated to 8KB.
I checked all the docs and I can see nothing mentioned about any limits on device writes. Given it clearly cut back the writes without even returning an error you'd think this would be mentioned somewhere! :-?
However, I wonder if it is AHI doing it or the driver has limits? Shouldn't matter as AHI is managing the data. In this case it's the HDAudio driver on an X1000.
I tested an 8 bit sample and it played fine. So looks like it may be for 16 bit only which doesn't make sense.
Does AHI device place artificial limits on sample length? And is this documented anywhere?
No, there should be no such limit. If you have problems it may be a bug/limitation of the HDAudio driver.
In PlayCDDA 1.6/1.7 I use 35280 bytes large buffers for the double buffered audio playback using CMD_WRITE (15 CDDA blocks of 2352 bytes each) and it didn't cause any problems on any of the systems I tested on, and I'm sure I've used larger buffers elsewhere as well.
@salass00
Thanks for commenting. I've been testing example code posted online that plays up to 128KB and modified it to play from 8 bit to 16 bit at 48Khz. So far it's worked fine. But I did notice length was cut down in 16 bit and more in stereo. This makes sense as the length in AHI is in sample frames.
I'm wondering if it is my code. I'm sure I must have made an error somewhere. I've checked my lengths and they are all long so that looks fine. But it clearly is cut short. Some thing is amiss.
I have no experience with the library API but if you use the device API then ahir_Std.io_Length should be specified in bytes and not in sample frames. If you specify number of sample frames in io_Length then that explains why the played length halved for 16-bit PCM and then halved again for stereo.
Sorry, I was unclear. I am using the device API and it does use length in bytes. What I was referring to is the debug output from the internal functions where internally device commands map to library function calls.
The problem is solved!
As I suspected the issue was in my code but I couldn't see where. It was in a buffering routine that checks for overflow and drops the length to buffer length if it's too large. As it turned out, there was an unknown bug where it didn't set length correctly, so it was cut short.