I've got graphics.library 54.248, as supplied with Update 2. As far as I know, that's the latest public release.

detail

And some drivers seem open source but still need a binary component. Like the ARM MALI drivers for example.

Using Printf from DOS worked and I updated the repository.

The test for STATIC NEWLIB with my public elf.library continues to show the second constructor not being called.

Quote:

That what I guestimated based on the numbers given by Hans

Audio frames != buffer sizes.

Quote:

From reading ahisrc, the hooks provided by the app get called as part of the hooks passed to the driver, even if the driver doesn't care about specifics.

The buffer is probably / possibly the same size though.

I don't agree:
- A 16bit HIFI mode takes 16bit samples in and always supplies 32bit mixing buffer to the driver
- AHI has to do resampling (and expand or shrink the buffer) when there is a mismatch between "audiomode frequency" and "input sample frequency" .
- The application can determine its own buffer size as input to AHI as long as it is equal or larger to the value returned by AllocAdio() AHIDB_MaxPlaySamples tag.

Quote:

Aha! I think this is the issue. AE will be setting the procesing frequency via AHIA_PlayerFreq and expecting the EffectOutputBuffer callback to be caled in sync with that, but your driver has forced AHI to process the data at a faster frequency due to the needs of the PCIe DMA resultng in the callback being called more often and thus it pushes the timer bar on faster than expected.

I don't know what the EffectOutputBuffer is. Is this the 16bit stereo sample buffer provided by AE4 to AHI?

Anyways, it indeed looks like AE4 is making wrong assumptions again:
- AHIA_PlayerFreq tag determines the frequency of application buffers supplied to AHI based on the following formula:

"Application buffer size" >= "driver buffer size" * "sample frequency" / "audiomode frequency"

AHIA_PlayerFreq = "sample frequency" / "Application buffer size"

So AHIA_PlayerFreq determines the rate at which frame buffers going into AHI. The wrong assumption by AE4 is that frame buffers will exit AHI to the driver at the same rate.

This could be the case when the driver relies on timing provided by AHI. In case of a "sample frequency" and "audio mode frequency" mismatch, AHI could resample and adjust buffer size to the driver but keep the buffer rate to the driver the same. So effectively the application is providing timing to the driver instead of AHI. And the driver needs to adapt it's own timing base on provided buffer sizes.

But in case of my driver, the audio hardware determines the buffer output rate:
If the sample frequency and audiomode frequency are both 48kHz then the minimum application buffer must be 1024*48kHz/48kHz = 1024. If the AE4 application buffer is set to 2000 than the player frequency is set to 48000/2000 = 24Hz. But my driver requests data from AHI at 48000/1024 = 46.875Hz. So if the AE4 cursor somehow counts how many times data is going out to the driver and compares this the value of the AHIA_PlayerFreq tag then the cursor will play at almost twice the speed in this example.

Quote:

If a solution can be found, then I could ask if an update could be made. He might say no though....

Maybe you can only ask one question: When will you make the source available as you've announced in the AE4 readme on os4depot.

At broadblues' suggestion, I tried changing AE4's sample buffer size (Options=>Preferences=>Performance), and it affects where the cursor ends after playback. Dropping it down to 1 extends the end position to 25.5 seconds. Putting it back to 10 returns it to the original ~24.7 seconds.

Anyway, once we figure out what AE4 is doing, perhaps we could update the ahi.device to hide the driver differences. I know it uses the low-level API but it shouldn't be so low-level that the application needs to know the mixing method.

Alternatively, does anyone still have contact with Davy?