tomaswoj Posted November 19, 2018 Share Posted November 19, 2018 Hi All, I tried to find some information but failed. What I'm playing with recently is generation of digital/volume-only music (to be more precises - basic sound as of now ). Just few days ago I found this nice Altirra Audio Monitor feature, that saved me already a ton of time, trying to debug my sample playback So first big KUDOS for that to the author! But where I'm getting confused is the following view (attached). What makes me wonder is why the [otherwise perfect] sin 'sample' on the first channel shows the lower frequency in the center of the view, and slightly higher frequencies (see how squeezed they become) on the edges, left and right, of the view. Is it just a presentation mode? Or it is really generated like that? Note that my generation/playback code is pretty simple. Just goes as fast as it can through the 'sample', and then repeats, and then repeats,... And nothing else is done in the main loop. Also - NMI is set to simple 'rti'. And I know that even with some NMI code I just get some short 'flatline' on that chart (so I don't think it is contributing to squeezing at all). I tried to make a comparison to a regular POKEY generated sound (channel 2), to see if it also follows the 'squeeze' presentation pattern, but apparently it is not. In the channel 2 case the sound frequency is perfectly equal in the whole audio monitor window. Also - this is just a static screenshot. But when it runs - the squeeze areas are staying at the edges of the view. They are not moving to the center, etc. So am I doing something wrong in the code? And it's because of that I see the occasional squeezes in the frequency? Or it is just the presentation matter (e.g. a fisheye view? to help with some better audio debugging)? The reason I'm digging it is the sound this perfect sine generates is not so perfect, still a bit noisy. But I'm not yet that experience to tell, whether it is because of the limited nature of POKEY digital sound capabilities (e.g. 4-bits only resolution for that) and so I will just have to live with it , or because of my poor code. Cheers svoy Quote Link to comment Share on other sites More sharing options...
antrykot Posted November 19, 2018 Share Posted November 19, 2018 (edited) Yes, this is what your program is really doing. The reason is DMA done by Antic, it slows down the CPU. You can press Shift+F8 in Altirra to see the actual pattern of Antic's memory access. Edited November 19, 2018 by antrykot Quote Link to comment Share on other sites More sharing options...
Rybags Posted November 19, 2018 Share Posted November 19, 2018 Using CPU delay loops for digital playback will be flawed whether there's screen DMA going on or not. The problem is that the refresh cycles are bunched up mostly in one part of the scanline, generally from just after the start of the visible display until around the middle. That in itself will introduce jitter to playback. Using Pokey Timers can be helpful either as IRQs or just polling the IRQST register - that way you've got that independent timing source and the jitter can be minimized. Quote Link to comment Share on other sites More sharing options...
R0ger Posted November 19, 2018 Share Posted November 19, 2018 Easiest sample playback is using WSYNC. WSYNC works even when no lines are displayed or during vblank. MPT tracker for example uses it for sample playback. Quote Link to comment Share on other sites More sharing options...
tomaswoj Posted November 19, 2018 Author Share Posted November 19, 2018 Yes, that was DMA, disabling it gives 'pure' sin wave with no frequency squeezes. Thanks! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.