Yes, that is the issue. Amiga programs simply assume too much and therefore misbehave.
When I truncate the recorded 24bit samples to 16bit and tag the buffer as AHIST_S16S then the startup error in HD-Rec disappears. HD-Rec seems to function normally now. A recorded sample has no distortion whatsoever and sound stops at the end of the sample. (sample recorded for 10 seconds is also displayed and played for 10 seconds) The program also has the option for digitally looping back the input to the output. So that explains the continuous recording and playback while the program is active. But this is weird since the monitor is active as well. So you overlay the digital and analog loopback with a slight digital delay. I think this option is available for soundcards without internal loopback capabilities. Also when you do not stop or mute your input than playback of recorded samples is mixed with the input (and even monitor). So yes, recording and playback works simultaniously as expected.
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.
Unfortunately I cannot find a way to detect the selected audiomode yet from within the driver. So there are two options at the moment: 1. Simply limit recording to 16bit like all other drivers seem to do (as far as I can tell from the AHI6 sources on os4depot.) 2. Add the recording sample format to the HDmixer and docky and let the user decide. This way you still can record in 24bit with AHIrecord.
Great progress in figuring out this mess! It's pretty typical that old software would make assumptions despite warnings in the documentation. Forgetting to do the checks comes with zero consequences...
Normally, developers would fix their software, but we're dealing with abandonware, so they've already left the building.
Quote:
Unfortunately I cannot find a way to detect the selected audiomode yet from within the driver.
According to this page, the application is supposed to write the desired sample format to ahir_Type in their first I/O request.
Quote:
I think I go for option 2.
Yes, please do. It's ugly, but we don't want to be stuck with early 90s audio forever.
It sounds like AHI itself could use some work. IIRC, AHI6 is GPL, but I can't find a source-code repository on GitHub, sourceforge, etc. I vaguely remember the website that hosted them shutting down (or something like that). Someone should have the latest code, but it really should be in a public repository.
According to this page, the application is supposed to write the desired sample format to ahir_Type in their first I/O request.
The AHI device has two ways for communication. Standard device IO interface (high level) and low level function calls.
The information that you point to is the standard IO interface but HD-Rec uses the low-level function calls. Haven't checked AE4 or AHIrecord and I am not going to make assumption.
Either way, the driver doesn't get this information.
And I fully agree about the software being stuck in the 90s. There is no stream format handling. So no way to pass on an AC3 encoded stream unmodified to the digital outputs through AHI. No master volume handling. Each application has to set its own volume. So each driver implements its own custom driver-mixer interface for handling master volumes, mute and preamps. There is only one output stream. So all input gets mixed into one output. No automatic handling of output direction based on connected cables. No monitor input selection. Only monitor volume control. And so on
Iirc the drivers are LGPL or some other licence. But AHI itself GPL.
So based on this, the sources for the modified OS4 AHI version should be available. But you can only make modifications that will not impact existing drivers. Additional flags should make this possible.
Edited by geennaam on 2023/1/3 7:37:06 Edited by geennaam on 2023/1/3 8:26:43
AHI sources on Aminet are 6.0. The OS4 port is 6.6. Based on my experience with the filesave driver, you need to make a lot of source modifications to make it build for OS4. And there's the issue of missing headers that can only be generated with some SFD tool from an old developer CD. So it would still be benificial to have the OS4 sources.
If it were up to me, we'd move it to GitHub or GitLab.
EDIT: The __AMIGAOS4__ macro is present, so it should be the latest version we use. Salass00 is listed as committing some changes, and he is an OS4 dev.
The archive on aminet might be labeled 6.0 release but the version of the ahi.device code contained within is 6.6 (I just double checked). Versions and build dates match with the OS4 bundled ones.
You may well be right that the Filesave driver needs further modification for OS4, no idea where the modified src might be, if so.
I just tried to build it from the src in the aminet archive, lots of warning, it gets to link stage, but fails, but the failures are all related to DOS deprecations and one Newlib related one. As the version numbers match I suspect it is the origial src, just that the compiler and SDK have moved on in the last 17 (!) years and made it troublesome to build.
fd2pragma can deal with sfd files IIRC. Though it's pain to have to do so.
I'd also give option2 the thumbs up, especially as there seems to be no way for the lowlevl API to request a given sample format.
Quote:
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 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.
@Hans
If you "master" the project does it play the project in sync? This uses the filesave driver so should eliminate driver incompabilty issues.
I'm thinking the 'playback cursor' is advanced based on how many samples played (it's not time related as such as when mastering the progress is as fast as the CPU can go.)
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."
About 10 years ago or so I tried to compile an AHI driver. So not even the whole AHI. My intention was to fix an issue in the SB driver for XE hardware. I had to do a lot of hacking around just to get to compile as the driver source or makefiles at least had already been hacked around so it could even compile on OS4 with an even then older compiler. The end result eventually compiled but all it did was crash and I gave up on the idea. Even back then it needed a clean up as it relied an old SDK and now it would be worse as the SDK has changed a lot now. I never kept old SDKs around. I don't know how it's compiled to this day. Does it still rely on the patches Davy made to it?
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.
Hmm slightly less than 2 x is odd, I would expect it to be slghtly over or exact.
Quote:
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."
OK so it does seem that the out of sync is driver related then, because filesave works as expected.
@geennaam
How does your driver handle the AHIET_OUTPUTBUFFER effect? Could there be any reason why the block size handled there would be different from that being passed in by AE4 in the playback hook?
If that seems a cryptic question, that's how the AE3 src drives the blockcount and thus the progress of the timebar etc.
How does your driver handle the AHIET_OUTPUTBUFFER effect? Could there be any reason why the block size handled there would be different from that being passed in by AE4 in the playback hook?
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 ). This triggers a AHI device call to my driver and the driver will return the amount of audio frames in pBufferLenght (1 stereo frame is two samples). In my case, the returned value is always 512.
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.
Well you kind of do in so much as the hook is called as part of the AudioCtrl->ahiac_MixerFunc hook that you presumably call from your driver at some point, else AE wouldn't be advancing at all, neither would the VUs in master slider be updating.
It looks like you may be calling that inside your loop for processing submitted data rather than just once per submision, I may be wrong, ofcourse, I just gessing based on apparent side effects.
Quote:
The application has to call AHI_GetAudioAttr( AHIDB_AHIDB_MaxRecordSamples, pBufferLenght ).
That's for recording. AE does call that and set the buffers to the right size, but that'snot the issue here.
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.
Both recording and mixing buffers are only called once. Meaning that the complete mixing buffer is transferred to the DMA buffers in one copy loop (no DMA because I have to do endian conversion). And the complete recording buffer is filled during an interrupt in the same way. 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.
This is the same with imported aiff samples. No matter the source. (HD-Rec, AHIrecord or internet)
So it could be that that AE4 once again makes decisions or trying to be smart based on certain assumptions. Or it could be something simple like mixing up buffer sizes for the marker timing which happens to be the same size in other drivers and therefore has no effect to the marker speed.
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.
Quote:
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.
Ah, so the way the other drivers work could be the actual root cause of audio stuttering problems rather than the graphics card & drivers...
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.
Quote:
In my case always 1024 audio frames.
That what I guestimated based on the numbers given by Hans
Quote:
All HOOKs are supplied by the AHI device with the AHIAudioCtrlDrv structure. So no specific flags or function calls from the application.
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.
Quote:
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.
The buffer is probably / possibly the same size though.
Quote:
[snip]. So no multiple calls to the same buffer.
OK so you aren't looping over the hook multiple times per buffer.
Quote:
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.
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 see how you can reasonably fix that at the driver end.
Quote:
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'm not sure what consequences the time marker being in the wrong place has.
Editing the sample at specific places will be harder, though when you move the cursor it will start playing from the correct place.
It might ot might not affect automation timing.
It possibly will affect punch in punch out recording, start and stop times.
One work arround might be to record parts with the direct driver, then edit after the fact with the audio.device drivers (UNIT 0: in the AHI mode requester of AE4) you would be limited to 44.1 or 48 KHz though. Which is usually OK anyway.
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.
That was less of a change than I originally expected, with my new logic above it shouldn't change much at all, but the changes could just be down to the number of whole buffers that get processed.
Quote:
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.
I think it must already as otherwise AE4 wouldn't be playing back smoothly, it's just this particular side effect of the rate the effectoutputbufferhook callback is called that can't be. (If I'm right).
Quote:
Alternatively, does anyone still have contact with Davy?
Actually yes, I have. Albeit very occasional. Usually in the context of the android AE5.
In fact I have had the AE4 source for about 6 months or so, but didn't want to say in public earlier as it's on a strictly personal use, ask Davy no questions about it, basis. I didn't want to mention this earlier as I didn't want to abuse the special favour he gave me in sharing it, better to reply usiong the publicly availabe AE3 src as reference. (This aspect is the same, although the hook itself is more sophisticated).
If a solution can be found, then I could ask if an update could be made. He might say no though....
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
