Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
43 user(s) are online (33 user(s) are browsing Forums)

Members: 0
Guests: 43

more...

Headlines

 
  Register To Post  

« 1 2 (3)
Re: Anyone have success using Audio Evolution 4?
Just popping in
Just popping in


See User information
@broadblues

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 didn't expect this method to be used much but didn't look into how AE4 mixes audio either. Most AHI clients working with multi tracks like module players don't use it and mix it all themselves. The AHIA_PlayerFreq and related AHIA_PlayerFunc are specific for module players as they are called like a timer interrupt and can support variable tempo changes like a normal player interrupt. Unlike a normal player interrupt, it doesn't cause live changes with a sound card, since the audio is buffered. Given it's an audio API, the use of the term frequency to set a timer likely wasn't the best the best choice, and looks confusing.

Go to top
Re: Anyone have success using Audio Evolution 4?
Not too shy to talk
Not too shy to talk


See User information
@broadblues

@broadblues

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:
OK so you aren't looping over the hook multiple times per buffer.


Correct.

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.

Go to top
Re: Anyone have success using Audio Evolution 4?
Home away from home
Home away from home


See User information
@geennaam

Quote:

Quote:

That what I guestimated based on the numbers given by Hans

Audio frames != buffer sizes.


Quite, I was working in frames....

Quote:

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.


Again I'm thinking in frames, your right the samples would likely get upgraded to 32bit for many drivers


Quote:

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?



No it's a buffer provided back to the application by AHI containing the final mix data, to enable it to implement VUs etc.

AE4 is using it for that purpose but also to 'count' the data finally written to the sound card.

Quote:

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.


Er yes, that's roughly what I said above (with more technical details ) .

A possible solution without too much redesign of AE4 is to check the number of frames passed back in the hook and calculate from there.

I'd be interested to know how you set up the driver based timing, as I have virtual driver project (that sent audio data to HDRecs mixer from external apps) that I could get to play but was always broken audio, probably because of timeing mismatches.

Quote:

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.


Don't know why he never released it. Perhaps because it was incomplete and didn't build. (I've regenerated the bits that were missing). Maye he just chnaged his mind

Go to top
Re: Anyone have success using Audio Evolution 4?
Just popping in
Just popping in


See User information
@Hans

Quote:
Alternatively, does anyone still have contact with Davy?


Davy is now developing an Audio Evolution in a mobile version. He is probably an administrator hiding under nick DWrae and I think that it would be easiest to make contact with him.

https://www.extreamsd.com/forum/index.php

The second option may be the contact form on the official website of Extream Software.

info@audio-evolution.com

Go to top
Re: Anyone have success using Audio Evolution 4?
Not too shy to talk
Not too shy to talk


See User information
@broadblues

Quote:
I'd be interested to know how you set up the driver based timing, as I have virtual driver project (that sent audio data to HDRecs mixer from external apps) that I could get to play but was always broken audio, probably because of timeing mismatches.

Without going into HDaudio specifics, the driver works roughly as follows:

My driver doesn't handle timing. The soundcard does.
It works in a typical master slave fashion where the HDaudio controller is the master and AHI the slave.
I think the following sequence applies to all PCIe DMA busmasters
1. The DMA busmaster is configured with the required duty cycle or data size. (In this case the audio DAC frequency)
2. DMA buffers are configured in main memory
3. Start is triggered by driver.
4. Busmaster starts fetching data from the DMA buffers and generates a PCIe MSI upon completion of each buffer.
5. Interrupt routine fills a DMA buffer with slave data and signals slave to prepare new data. (in this case a copy loop from mixbuffer to dma buffer and a signal to AHI upon completion so AHI can start mixing the next buffer)
6. repeat 4 and 5 until stop

AHI doesn't push data in this mode, it simply prepares data in a hook buffer and waits until the data has been handled.

Simple but elegant

All the other AHI drivers basically use AHI as master and the sound hardware as slave. This only makes sense for old audio hardware which is not DMA capable. But then you need to compensate for the mismatch between host clock and codec local oscillator. A 20ppm mismatch doesn't sound much but results in 20ppm*48kHz=0.96 samples/second. Could be that AHI takes care of this issue. Nevertheless you need to keep an eye on the sound hardware FIFO/buffer for under-/overruns.

Go to top
Re: Anyone have success using Audio Evolution 4?
Home away from home
Home away from home


See User information
@geennaam

Thanks for the updated driver. I can now record in Audio Evolution, which means I can also listen to previous tracks while recording the next one (not possible if another program is doing the recording due to exclusive access).

Hopefully Davy will let broadblues release an update that addresses the playback cursor issue...

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top

  Register To Post
« 1 2 (3)

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project