Jump to content
IGNORED

Altirra Audio Monitor - question on volume-only presentation


tomaswoj

Recommended Posts

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

 

 

post-32563-0-19471800-1542623776.png

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...