When I record a sample, then play it back at the same time I record a second sample, then finally play them together, they do not “line up”.
(Assume that the lag-time in the code is not to blame, since the record and playback commands are so close together.)
Why is there a delay?
- coolbeans asked 13 years ago
What I am doing is I am simutaneously recording a new sample while the previous sample I recorded plays back. I need to start recording a sample EXACTLY in parallel with whatever is playing back. I am getting a delay with the playback function.
Ultimately I’m asking: “Why is the FSOUND_Record_StartSample function much faster then the FSOUND_PlaySoundEx function.
yeah, that sounds like that could be a possible source for the problem, but what can I do to start fixing it?
I think it’ll be hard to get them playing at EXACTLY the same time, unless it’s done internally in the mixer. You could however try setting the buffer length to a known value ( say 200, which seem to be the max used by a driver ) with:
int len_ms = 200;
FSOUND_SetBufferSize( len_ms ); // len_ms = 200
// call FSOUND_Init() after this etc
FSOUND_Play( preRecordedSample );
Sleep ( len_ms ); // ( might be better with a highPerformanceTimer )
not sure if that’ll make it in sync due to mixing speeds etc, but it would assumably be closer to synced. ( possibly inaudibly unsynced )
That’s assuming you can do no post-processing at the sounds, then you could examine the sample and sync them that way. ( or sync them in an external application 😛 )
I’m still a newbie when it comes to FMOD, but I assume that any suggestions are worth testing
I think DEVLiN understands my problem… maybe i’m not explaining it correctly:
- Foot pedal switch #1 activated (via RS232 port) -> Start recording Sample A.
- Switch #1 activated again -> Stop Recording Sample A, Playback Sample A, Start Recording Sample B.
- Switch #1 activated again -> Stop Recording Sample B, Playback Sample A and Sample B, Start Recording Sample C.
- Switch #1 activated again -> Stop Recording Sample C, Playback Sample A and Sample B and Sample C, Start Recording Sample D.
This forms a staircase looping effect ideal for making a fun little state program that records tracks of musical samples and plays them back simutaneously. I think its a cool idea.
But now maybe you can see the importance of “lining up” each recording to the rest of the playing samples… they really can’t be off more then a few milliseconds.
I tried DEVLiN’s idea of delaying the recording and it is much better, although I am using a poor timer (I only have a resolution of 100ms to work with which sucks).
Brett, is there a way to maybe load the buffer of the mixer, and figure out when it is full, then release the buffer to the output? Maybe that’ll work??
Another question I have is regarding the recording example included with FMOD:
I see that you have an algorithm that keeps the playback cursor just behind that of the recording cursor (reverb echoy effect). If I were to start playing back two or more samples at the same time, by how much would their positions at anytime differ? Would I NEED a similar algorithm to monitor any straying sample positions from my specified cursor?
Thanks for your help!
A Callback function for when the mixerbuffer has been filled would maybe solve your problem.
But. How about this ( ugly hack to maybe make it work ).
IF FSOUND_Stream_SetEndCallback calls the callback function when the actual stream has stopped playing ( audibly, not just in the end of the mixer ) you could maybe do this.
Record first sample.
Set the first sample up as a stream, set a callback with:
to stop the recording from the callback, either directly or via a flag for your main loop.
Play the first sample as a stream and start recording the second sample directly after.
Now, once the callback is called, your second sample will stop being recorded.
After that, you post process it by comparing the length of the two samples, and removing the difference from the beginning of the second sample.
Since they end simultanously, removing the difference in length should make them start simultaneously and thus making them in perfect sync.
It’s worth a try 8)
Good idea, but the total length of each sample doesn’t really matter; what matters is when it starts. Pretend t is time, R1 is the recording of sample 1, and P1 is the playback of sample 1, and so on…
R3 |—I can’t tell which beat to start playing on—|
You can see the problem starts early on, so I think I need to know the (lag)time before I even press the record button. So far I have done this…
[tim] = timer
R3 |—yay, my tracks match, almost—|
what would be ideal is if I could do this somehow…
R3 |—yay, my tracks match, perfectly—|
Any other ideas?? Thanks
[quote="coolbeans":3ki0ssua]You can see the problem starts early on, so I think I need to know the (lag)time before I even press the record button.[/quote:3ki0ssua]
Well, if you stop recording R2 at the instant P1 stops playing you already know the (lag)time. ( that was the whole point with my previous post )
(lag)time is the difference in length of the two recordings ( since they end at the same time ) – you can even see it in your drawings.
To follow your example:
Now, post process R2 by removing the difference in length samples from the [b:3ki0ssua]beginning[/b:3ki0ssua] of R2 like so:
len(P2) – len(p1) = 4 dashes.
Then when you play them both back at the same time you would get:
et voila, they match perfectly.
Then you just repeat it with p = (p+1). ( only difference you would get is the added time from more function calls, but it should really be negligable )
It should work
Please login first to submit.