Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
114 user(s) are online (61 user(s) are browsing Forums)

Members: 0
Guests: 114

more...

Headlines

 
  Register To Post  

« 1 (2) 3 »
Re: Anyone have success using Audio Evolution 4?
Quite a regular
Quite a regular


See User information
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.

I think I go for option 2.

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


See User information
@geennaam

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.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: Anyone have success using Audio Evolution 4?
Home away from home
Home away from home


See User information
Sourceforge page:
https://sourceforge.net/projects/arp2/files/ahiusr/

But no source listed, maybe salass00 can help

Sam440ep Flex 800Mhz 160GB HD + AmigaOS 4.1
Go to top
Re: Anyone have success using Audio Evolution 4?
Quite a regular
Quite a regular


See User information
@Hans

Quote:
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

Go to top
Re: Anyone have success using Audio Evolution 4?
Quite a regular
Quite a regular


See User information
@samo79

The AHI 6.0 source is available on aminet.

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
Go to top
Re: Anyone have success using Audio Evolution 4?
Home away from home
Home away from home


See User information
@geennaam

Quote:

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


I don't think the AmigaOS4 version of AHI 6 is modified in any way. As far as I know (might be wrong but 95% sure) it's straight "port".

Only the example drivers are (L)GPL though, so unfrtunatly sources of the various other drivers aren't freely available.

Go to top
Re: Anyone have success using Audio Evolution 4?
Quite a regular
Quite a regular


See User information
@broadblues

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.

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


See User information
@geennaam

I just checked out the code from the link that samo79 gave, and it could be the actual latest code. Ahi.device is v6.7.

The v6 code isn't in the trunk, but in a separate branch: https://svn.code.sf.net/p/arp2/code/ahi/ahisrc/branches/BRANCH_6.

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.

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: Anyone have success using Audio Evolution 4?
Home away from home
Home away from home


See User information
@geennaam

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.

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


See User information
@geennaam

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.)

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


See User information
@broadblues

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."

Hans

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: Anyone have success using Audio Evolution 4?
Just popping in
Just popping in


See User information
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?

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


See User information
@Hans

Quote:

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.


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.


Edited by broadblues on 2023/1/3 12:17:03
Go to top
Re: Anyone have success using Audio Evolution 4?
Home away from home
Home away from home


See User information
@geennaam

Digging through the AHISrc it seems you wouldn't be calling it direct but via the
AudioCtrl->ahiac_MixerFunc hook.

Could you be calling that more than once per block of submitted data?

Go to top
Re: Anyone have success using Audio Evolution 4?
Quite a regular
Quite a regular


See User information
@broadblues

Quote:
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.

HD-rec does does correctly. See post #20 step 4.

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


See User information
@geennaam

Quote:

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.

Go to top
Re: Anyone have success using Audio Evolution 4?
Quite a regular
Quite a regular


See User information
@broadblues

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.

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


See User information
@geennaam

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?

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: Anyone have success using Audio Evolution 4?
Home away from home
Home away from home


See User information
@geennaam

Quote:

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.

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


See User information
@Hans

Quote:

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....

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-2023 The XOOPS Project