I do not know how the AHI device works but let's see what AHI tells us with debug output enabled (AHI debug level=FULL in sounds prefs advanced settings tab)
When I execute HD-Rec_OS4 from workbench the following sequence happens:
1. Call to AHI_AllocAudioRequest() with some default values (44.1kHz, stereo etc) -> Open requester for AHI mode selection
2. Call to AHI_AllocAudioA() with user selected AHI mode, HOOK functions (AHIA_SoundFunc, AHIA_PlayerFunc, AHIA_RecordFunc), channels etc. The interesting part is the tag called AHIA_RecordFunc because I think this is the one that the error is about.
3. Call to AHI_GetAudioAttrsA() with tag AHIDB_MaxPlaySamples -> Minimum number of audio frames in memory
3a. Call from AHI.device to driver to request play buffer size
4. Call to AHI_GetAudioAttrsA() with tag AHIDB_MaxRecordSamples -> Number of sample frames that AHI will return when the HOOK Function of AHIA_RecordFunc is called.
4a. Call from AHI.device to driver to request record buffer size
5. Call to AHI_GetAudioAttrsA() with tag AHIDB_MaxPlaySamples -> Don't know why this is being called again
5a. Call from AHI.device to driver to request play buffer size
6. Call to AHI_LoadSound() -> Prepare to play a sample buffer of type AHIST_DYNAMICSAMPLE
7. Call to AHI_LoadSound() -> Prepare to play a another sample buffer of type AHIST_DYNAMICSAMPLE
8. Call to AHI_GetAudioAttrsA() with tag AHIC_MixFreq_Query -> Get the current mixing frequency
9. Call to AHI_GetAudioAttrsA() with tag AHIDB_MaxRecordSamples -> Don't know why this is being called again
9a. Call from AHI.device to driver to request record buffer size
10. Call to AHI_ControlAudioAttrsA() with tag AHIC_Input -> Select Input source
10a. Call from AHI.device to driver to Select Input source
11. Call to AHI_ControlAudioAttrsA() with tag AHIC_MonitorVolume -> Request Monitor volume
11a. Call from AHI.device to driver to Set Monitor Amp Volume
12. Call to AHI_ControlAudioAttrsA() with tag AHIC_Output -> Set ouput (in this case to all available outputs)
12a. Call from AHI.device to driver to Enable all outputs
13. Call to AHI_controlAudioAttrsA() with tag (AHIC_Play, TRUE) -> Signal AHI to start playing (the sounds in steps 6 and 7?)
13a. Call from AHI.device to driver to start playing the samples provided at the frequency selected by the user in step 1
14. Call to AHI_ControlAudioAttrsA() with tag (AHIC_Record,TRUE) -> Signal AHI to start recording (return samples to aplication with HOOK function AHIA_RecordFunc provided in step 2?)
14a. Call from AHI.device to driver to start recording
15. Call to AHI_SetFreq() -> Select frequency to the frequency selected by the user in step 1
16. Call to AHI_SetVol() -> Sets some kind of volume but I do not see a call to the driver for adjusting the output amp volumes
17. Endless calls to AHI_SetSound(). At this point the requester about the" Driver bug" occurs. And continues when the error window is closed
Main window of HD_Rec opens -> Still endless loop of calls in step 17
End HD-Rec program
18. Call to AHI_ControlAudioA() with tag (AHIC_Play, FALSE) -> Signal AHI to stop playing (rogue call from step 17 was interfering with this debug output line)
18a. Call from AHI.device to driver to stop playing
19. Call to AHI_ControlAudioA() with tag (AHIC_Record FALSE) -> Signal AHI to stop recording
19a. Call from AHI.device to driver to stop recording
20. Call to AHI_FreeAudio()
21. Call to AHI_UnloadSound() -> Unload sound from step 6
22. Call to AHI_UnloadSound() -> Unload sound from step 7
23. Call to AHI_FreeAudioRequest()
Apparently the endless loop in step 17 is how this program works. Just endless playing and recording.
I have checked the debug info of my driver and is indeed in an endless playing and recording loop
But while browsing through the SDK, I've found this little remark about the AHIA_RecordFunc:
"....
AHIA_RecordFunc (struct Hook *) - This function will be called
regularly when sampling is turned on (see AHI_ControlAudioA())
with the following parameters:
A0 - (struct Hook *)
A2 - (struct AHIAudioCtrl *)
A1 - (struct AHIRecordMessage *)
The message (AHIRecordMessage) is filled as follows:
ahirm_Buffer - Pointer to the samples. The buffer is valid
until next time the Hook is called.
ahirm_Length - Number of sample FRAMES in buffer.
To get the size in bytes, multiply by 4 if ahiim_Type is
AHIST_S16S.
ahirm_Type - Always AHIST_S16S at the moment, but you
*must* check this, since it may change in the future!
..."
Apparently AHI assumed 16bit ADCs at the time of writing. But HDaudio has progressed to 24/32bit. So my sample buffers are returned in format ahirm_Length=AHIST_S32S. And it looks like both HD-Rec and AE4 ignored the
*must* part and assume 16bit signed samples.
This is the only way that I can explain the behaviour.
AHI will only tell me to play and record at a certain frequency. But it doesn't tell me anything about the resolution. When playing, I always get a 32bit buffer for HIFI modes. So I automatically select the best mode available. When recording, I have to return the resolution/format in the AHIRecordMessage along with a pointer to the record buffer and the amount of sample frames. Apparently this is passed on 1:1 to the application.
But since there are programs out there that are making assumptions, I could try to discover the selected audio mode from driver side and adjust the sample buffer accordingly.
Edited by geennaam on 2023/1/2 19:18:01
Edited by geennaam on 2023/1/2 19:24:15
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
Only V3 was released AFAIK.
.
