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?

Similar to recording, the playback sample buffer has to be requested by the application as well.

In my case always 1024 audio frames.

All HOOKs are supplied by the AHI device with the AHIAudioCtrlDrv structure. So no specific flags or function calls from the application.

I don't think that the application hook and mixing hook point to the same buffer because AHI has to do some mixing first before the audio data is presented to the driver.

[snip]. So no multiple calls to the same buffer.

My driver works in a different way compared to other drivers. I do not use mixing routines with timing provided by AHI. Instead, the audio hardware determines the timing. This is the only correct way to feed PCIe DMA busmasters.
FLAGs are correctly returned in AHIsub_AllocAudio so AHI is aware of the diver running in this mode.

After all, Recording and playback works just fine. I have double checked the AE4 behavior and when I record for 5 seconds, it also displays a 5 seconds sample. It is just that the playback marker plays at almost twice the speed and stops almost twice the length of the recorded sample But both recorded sound and playback are fine audio wise.

I don't handle this. It is part of ahi.h (device stuff) and not ahi_sub.h (driver stuff). So it is only something between the application and the AHI device.

The application has to call AHI_GetAudioAttr( AHIDB_AHIDB_MaxRecordSamples, pBufferLenght ).

Quote:

So the sample recorded by AE4 appears twice as long? What exactly do you mean by that? It seems odd especially as you mentioned the sample actually played correctly.

It's not exactly 2x. My test sample is ~14.3 seconds long, and the playback cursor ends at ~24.7.

Quote:

If you "master" the project does it play the project in sync? This uses the filesave driver so should eliminate driver incompabilty issues.

The playback cursor stops at the end of the sample, so I guess that it is "in-sync."

I can also record undistorted sounds in AE4 now. But unlike HD-rec, AE4 still thinks that a sample is almost twice as long. This is also still the case for imported 16bit AIFF samples that were created with AHIrecord. And while AE4 looks like a nice program, I do not plan to fix all bad programming.

So based on this, the sources for the modified OS4 AHI version should be available.