So no one know about possibility to assign "tab" key to switch between Filer's listers when any Filler's lister active ?

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.

Sounds like I should try to find an audio file format converter to see if I can export something that works.

Could you test playback of files recorded with AHIRecord on your machine? That would be a quick way to check if it is indeed a file format issue.

The only way I see it being an audio driver issue, is if AE4 expects some kind of driver feedback to be exactly what Davy's drivers return. Even then it's still most likely an AE4 bug.

Ok, we are clearly out of sync so I stop here.

Yes, I can select the correct input (Don't mistake enabled sound for the correct input.)
The monitor will feedback audio to the linout and hp out no matter if you have selected the correct input to the ADC. The monitor will provide sound for any valid input.
(This will result in free mixing when recording from the monitor input instead of mic/line because the monitor itself will provide the hardware mixing for you)

Be aware that MIC inputs will give two channel mono. Only Linein will give real stereo.

Now for the not working part.
When I attempt to record from linein in the AE4 record window, the right channel is noise and the left channel is distorted. Even with the recommended HIFI 16bit Stereo++ mode at 48kHz.

Recording works fine with AHIrecord. (Which I have used to verify the driver)

When I record a sample with AHIrecord in 16bit AIFF format then this sample plays fine with multiviewer and AmigaAmp. But when import the same sample in AE4 then the sound itself is fine but the progress cursor/line thinks that the sample is about twice as long.

I do not know what dark magic is performed in the drivers written by DW that AE4 apparently works fine with those drivers.

Why recording doesn't work within AE4 is also a complete mystery to me. Could be that there are also some hidden DW driver communications to circumvent the limitations of AHI.

Be aware that AHIrecorder isn't perfect either. The "Monitor" selection doesn't work at all. It shows the outputs instead of monitor inputs but nothing happens when you select anything in the monitor. I can't see any request being fed to the AHI driver. So maybe AHIrecord makes assumptions or relies on hidden direct driver communication as well.