High-resolution oscilloscope

[cyto]

This is perhaps related, like a distant cousin, to my own little "trick" of setting my test oscillator to 187.5hz when Im viewing signals.
At that frequency (or multiples of that like 375Hz, 562.5Hz, 750Hz...using a samplerate of 48kHz) the oscilloscopes signal is frozen perfectly, just as your experiment shows. That trick is samperate related. If I change my samplerate from 48kHz to 44.1kHz I loose the "sync"

Not too distant a cousin!
48000 / 187.5 = 256

I bet the "lock frequency" at 44.1kHz is 172.265625Hz

Interesting thought about the soundcard buffer. I hadn't even considered that it would have an effect. When I have time later tonight, I'll do some tests.

-cyto

[aliasant]

This is perhaps related, like a distant cousin, to my own little "trick" of setting my test oscillator to 187.5hz when Im viewing signals.
At that frequency (or multiples of that like 375Hz, 562.5Hz, 750Hz...using a samplerate of 48kHz) the oscilloscopes signal is frozen perfectly, just as your experiment shows. That trick is samperate related. If I change my samplerate from 48kHz to 44.1kHz I loose the "sync"

Not too distant a cousin!
48000 / 187.5 = 256

I bet the "lock frequency" at 44.1kHz is 172.265625Hz

Interesting thought about the soundcard buffer. I hadn't even considered that it would have an effect. When I have time later tonight, I'll do some tests.

-cyto

There are definetly things to learn here but right now Im way to tired to even try

[trogluddite]

Great work, Cytp - the addition of the peak and DC readouts is a masterstroke.

I added a couple lines into the code that manipulates when the sampled values are being assigned to the exported arrays

This is looking like a very interesting technique - though there are still some mysteries that I haven't quite got my head around yet! I'll stick my neck out and see how I'm doing so far...

44100/256 = 172.5Hz - so blocks of 256 samples can be generated much faster than ticks.
There is no explicit "signalling" between the code and the mono to graph - the code does not know when a tick has happened, nor a frame drawn - and the ticker does not know any of the code's variable values.
From which I deduce...
There is an implicit "frame size" for the receipt of triggers from the windows timer (ticker) - triggers to the 8*Graph can only occur at 256 sample boundaries. Indeed if count1 is loaded with a non-zero value in stage(0), the whole graph is "rotated" - but never drifts.
Effectively the routine that reads the windows timer, and generates triggers from it is using a hop(256), synchronised to the sample sample counter (ecx) used for all other hops.
Your buffer is filled at the desired rate (appropriate to the zoom) - and the reading out is a continuous loop at sample rate, but (here I am completely guessing!) the clock for this is advacned/retarded based on the write index.

This is a real revelation to me - not only is your scope fantastic (the "analytical" complement to my "low CPU, but sketchy" version) - but I think that you have discovered something really fundamental about the inner workings of SM that I have never seen before.

[cyto]

This is a real revelation to me.

You and me both I'm still exploring/testing/debunking this little "trick". Any further insight would be definitely encouraged. Getting back to the scope: FWIW, the code block always has a 256-sample copy of the "readouts" of the scope in its internal memory. The output to the graphs is generated by simply continually cycling through those arrays (as I said earlier, the trick was figuring out how to internally update that array). No matter when the graph is captured, it should output a perfectly synced version of the internal array. You'll notice that there is a stage 0 routine that resets all of the counters to 0. This is there because I noticed that sometimes, SM will retain values in its memory even when the stream is reinitialized. In order for this to work, those counters must be reset.

I am certainly interested in any discoveries made on the 256 "magic number". I can already imagine some very cool things that could be done with this little bit of knowledge.

EDIT: I see you already figured out about the counter reset. I should have read your post more carefully

-cyto

[cyto]

HOLD THE PHONE!!!

Aliasant was right! The ASIO buffer definitely makes a difference in the capturing of the graphs. Back to the drawing board.

-cyto

[cyto]

Did I mention my obsessive/compulsive tendencies?

You can extract the current ASIO buffer size from the ebp register!!!
(you need to copy it to the eax register first (for some reason) or else SM will crash)

asioBufferValue.png (14.05 KiB) Viewed 1546 times

Scope update coming soon!

-cyto

[trogluddite]

This gets more and more interesting with every post!
By complete fluke, my ASIO buffer was set to 512 (crappy netbook!) - so your scope had worked perfectly!.
And, as expected, when changed to a non-multiple of 256, the display went bonkers.

You can extract the current ASIO buffer size from the ebp register!!!

He he, and to think I posted this mere hours ago...

I think some other registers are also used internally by SM - I guess that is why the assembler only recognises 'eax' for most of the x86 opcodes, and why 'ecx' must be copied into 'eax' before calculating hops

I have done a little fiddling with the other registers before - but gave up when I found that SM will often highlight the syntax as though valid despite the opcodes not working (or crashing, as you have already found!) Even pushing/popping the values doesn't seem to always fix that either, so I guess the assembler simply doesn't compile the opcodes properly.

BTW) You can also get the buffer size from the string output of the ASIO Out primitive (with a little parsing) - maybe useful if needed in "green".

[aliasant]

HOLD THE PHONE!!!

Aliasant was right! The ASIO buffer definitely makes a difference in the capturing of the graphs. Back to the drawing board.

-cyto

Glad I did something right for a change :=)

[DigitalWhiteByte]

Interesting nice to see so many minds at work

[cyto]

Okay. I have discovered a few things. My previous revelation about the ebp register should be interpreted with a healthy amount of skepticism. First of all, it does not simply contain the array size (-1) of the asio buffer, but rather continuously "ramps" an integer value from zero to the buffer size (-1). The reason the m2f only outputs the buffer size can actually be found in the demonstration from a few posts back. Like the "mono to graph"s, the mono to float orients itself to the right of the buffer size, so I was only seeing the last value of the increment. Secondly, the ebp register is simply a copy of the edi register, which I would argue may be a better choice for accessing this type of information. This makes sense if you analyze the code compilation of the schematic. The edi appears to be the cyclical index of the code. The data in this register is passed to the ebp register in order to locate the necessary data to access (for output).

I will say that the more I burrow down this rabbit hole, the more I am convinced we are treading in dangerous waters (sorry to mix metaphors, and even sorrier to the non-native English speakers ). I do believe that there are many new "tricks" waiting for the adventurous, but after countless crashes and one BSOD, I think I might put this on the back burner for awhile. I do intend to try to fix the scope that I posted earlier (wasn't that what we were talking about?).

-cyto

[trogluddite]

My previous revelation about the ebp register should be interpreted with a healthy amount of skepticism

For sure - on my netbook, I don't even seem to be able to read ebp, just trying to use "mov eax,ebp" causes a crash!
That's a real shame - this was all starting to look interesting - but a reliable way to get the buffer size will be needed to get the "frame sync" right. It can be got at as a string from the ASIO out code - but that's not much use for VST exports or DS users.

[DigitalWhiteByte]

Found solution to extract the current audio buffer size.

tell me if it works for everyone.

[nix]

It's working here

[aliasant]

It's working here

Works here too but this reminded me of an odd behaviour when changing buffersizes.

If I change from one buffer to a larger buffer all is well but if I change from a large to a smaller buffer I need to clear the audio before it works.
Can anyone confirm that ?

I guess were all waiting for Trogs fabulous laptop now?

[trogluddite]

I guess were all waiting for Trogs fabulous laptop now?

Yup, that seems to be working just fine here - nice work DWB!