| Re: [hatari-devel] Sample frame buffer is incorrectly restarted |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Le 09/02/2024 à 20:43, Miro Kropáček a écrit :
On Fri, 9 Feb 2024 at 20:01, Nicolas Pomarède <npomarede@xxxxxxxxxxxx
<mailto:npomarede@xxxxxxxxxxxx>> wrote:
forgot to ask, but can you send the updated version with the
printf's of
the "play.tos.zip" file you sent earlier ?
also, can you confirm you're using the same sox command as eero to
convert a wav/mp3 to raw falcon sound ?
or better, could you post a 20-30 sec raw file that sound OK on falcon,
just to be sure the sound quality problem eero reported is in Hatari
and
not in some conversion steps ?
Sure, no problem:
https://mikro.naprvyraz.sk/private/play/play.tos
<https://mikro.naprvyraz.sk/private/play/play.tos>
https://mikro.naprvyraz.sk/private/play/EN16.RAW
<https://mikro.naprvyraz.sk/private/play/EN16.RAW>
Put in the same folder and run. I sincerely apologise for the choice of
the track, it was the first one I found on my disk. ;-)
Btw, as expected, this solution was utterly stupid. In the meantime I
have coded a routine which doesn't depend on the frame address
comparison and in general is 3x simpler. So this is now purely for
educational purposes.
Hi
latest devel version should now be closer to Falcon.
most noticable difference that prevented it from working is that on
falcon the soundint signal that goes from the DMA chip to the MFP is in
fact inverted compared to STE/TT.
On falcon, signal is 0/LOW when DMA is playing (or recording) and it's
1/HIGH when DMA audio is idle.
With default MFP's AER content set by TOS, this means that the Falcon
will trigger interrupt on TA input or GPIP7 at the start of every audio
frame, not at the end as on STE/TT.
And this is why they added reg FF8900 to also trigger interrupt at the
end of an audio frame.
Regarding your test program, it can't work at the moment under Hatari
because it requires precise cycle counting, which is not available for
68030 now :
1) your program wait a fixed 500 VBL as a pause in your main loop ;
note that this will only work when running at 60 Hz. At 50Hz, playing
one frame of sound will take ~210 VBL, so your main loop will go out of
sync, even on a real Falcon.
A better solution would be to wait just 1 VBL, this way it should work
also in 50 Hz or any freq.
2) I don't understand why your TimerA function sets "muted=1", which
will briefly stop dma sound and start it just after. The whole point of
the DMA sound and timer A is that you can use it to seamlessly chain
audio frames without stopping/restarting DMA
DMA will buffer the start/end addresses as soon as it start playing,
which will trigger the TimerA.
So in TimerA you can immediately write the start/end address of the next
frame, it will be buffered until the current frame is played and the
next frame should be started just after (you need to set "loop mode" for
this)
you can even swap logical/physical buffer in TimerA instead of in main loop
Then in your main loop you just have to monitor a variable that tells
you which buffer is actually playing and load data in the other buffer
(which will be swapped during TimerA)
Maybe that's why you called your solution "utterly stupid" ? :)
Nicolas