reaper no playback sound after switching rate #56
Comments
|
This may be related to the crashing control panel #52 |
|
You can notice that something broke in reaper: when it did, these messages do not appear in the system.log anymore when you switch out of reaper: This break seems to happen right when you start your first sampling. Reaper seems to break in a lighter way when you play back something and then stop and change the rate. It won't play back then but if you switch out of reaper and back into it, you have it working again at the new rate. |
|
I see messages like this in the console when switching rates in reaper this is weird, it is changing only the input rate I think , not the output rate. |
sorry, that is a misunderstanding, I often have no sound after switching sample rate, so I said it "breaks the sound" meaning it is broken. so I have the same situation as you, or very close. |
|
Thanks for the clarification. I thought his was a different issue. |
|
Here is another sample, I see this when switching to 48k to 44k I see swice a call to performFormatChange! And there is a call to performAudioStart, immediately followed by stopUSBStream and then the 2nd performFormatChange? Both are for direction 0. |
|
1st call to performFormatChange changes the output rate. The 2nd call changes the input rate. What may be happening is that reaper sets both input and output rates separately, shortly after another. |
|
From above logs it seems that the driver changes only 1 stream rate (eg, output stream) at a time, then restarts the engine (if we're in Reaper), then gets the request to change the other (eg, input) stream, stops the engine, etc. But at a deeper level, performFormatChangeInternal sets both channels to the new format only if the sampleRateChanged. Only when the message "Changing sampling rate to XXX" appears, both streams get a new sample rate. |
|
Complared with switching the rate of the EMU using the control panel while playing with Quicktime Player 7. The difference between the two is that Reaper does a second round of 'new format'. (supposedly through setFormat ). Here is the full dump: |
Wouter1
changed the title
|
I was not checking&reporting errors if the output stream does not start up properly. Added check. |
Wouter1
added a commit
that referenced
this issue
Mar 29, 2015
|
That did not reveal any issue. So the startup is not failing |
|
When the audio breaks, the calls to writeCompleted still arrive properly. So we are writing data to the EMU and it arrives there. |
|
Version 3.4.0 did not have this problem. Version 3.5.0 does have the problem. So the problem was introduced between 3.4.0 and 3.5.0 |
|
Tested that pollInterval=4 modes do not cause this issue - pollInterval=8 modes also don't work anymore after switching the rate. |
|
I tested recording with reaper after switching the rate, using a different source for the sound (not the EMU). Recording works fine also after changing the rate. So it is definitely the OUTPUT ONLY that is not working. |
|
clipOutputSamples is being called also when the sound is not working anymore. |
|
The clipOutputSamples call contains audio data (it's not containing only zeros). |
|
Checked that the frameSizeQueue is cleaned at start. It is, in init() which is called from startUSBStream() |
|
If I add a check to return immediately from performatChange if the rate has not changed, it still does not work from reaper. It seems the audio breaks just from the quick cycling of stop, start, stop, start. The rattling noises I sometimes get suggest that the problem is related to the erase head. |
|
Confirmed, turning off the erase head solves this issue (but of course that would cause other problems). This all suggests we cause a problem in CoreAudio when quick start/stop cycling Maybe CoreAudio expects that we keep a sync lock while switching rate?? |
|
We are losing sync after the rate is switched from reaper 48k rate This is a proper startup and this when it goes wrong also at 48k |
|
Notice, it goes wrong already at the first input wrap:
should be
We have 24 samples per frame, 64 frames per list and 8192 samples in the ring sample position 8 = byteposition 48 |
|
Checked that the inputstream rinngbuffer is at position 0 when the sampling starts. Seems OK |
|
frameIndex is not set to 0 in start! The reading of the input stream was starting at the wrong point and therefore the first wrap came at a wrong position causing timing mechanisms to resync and probably this was confusing the coreaudio. |
Wouter1
added a commit
that referenced
this issue
Apr 6, 2015
…nge of sample rate occured while running audio
|
First tests look sound OK. This missed init call seems so essential that I committed immediately to version 3.5.4. Thorough testing will take more time |
|
Checked that the reported latency at 96k is correct with default driver. |
|
testing default driver 4.2ms. full playback-record cycle from reaper. Reaper block size 64. Playing 10minute 440Hz sine (generated from audacity) from reaper. Recording to new track. Right click on recorded track and select 'render item as new take'. The track is then rendered as wav in the Documents/Reaper media directory. Using audacity on that file to do 440Hz notch filter. Checking for clicks
At 192k I also see very low level noise spikes (around -50dB). They are 1 sample wide and occur sometimes many times per second, it sounds and looks like cosmic radiation pulses. |
|
@TomDrinkwater |
|
Still need to test with 1ms driver setting |
that's great, thanks for all your work! sorry I have been out of action, I will try this new version tomorrow. |
|
CHecked that the reported latency at 44.1 is reported ok with 1ms driver. Reaper reports 4.4/4.1 and actual roundtrip latency 8.48ms. Checked reported latency of 2.4/2.3ms latency at 192k. Roundtrip is 4.8ms so correct. Checked reported latency of 3.0/2.9ms latency at 96k. Roundtrip is 5.97ms so correct. |
|
testing driver with 1ms setting and 64samples daw buffer.
|
|
@TomDrinkwater good to hear you are still around. I'm particularly interested if this fix also fixes #55. |
|
what is the version number for this driver? is it 3.5.4? I tested it but I still have clicks at 96k 1ms plist setting. also sometimes have no sound after sample rate change, but sometimes it works... |
|
96k 64 samples 1ms - about 7 clicks in 3 mins 48k 64 samples 1ms - 1 click in 10 mins sample rate changing is now behaving correctly. but at first I had the same bug with no sound.... it seems to behave better if the control panel is not running, but I haven't tested that enough to be sure. |
|
Thanks Tom for testing! So I understand that the rate switching is now working but you still have clicking? Then I can close this ticket but need to look more into #55 |
Closed
at first with the new driver I had the same problems with sample rate switching. but after a while it got better. I'm not sure why! I will have to see if the problem returns to be sure. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Since v3.5.1 switching the driver sample rate behaves erratically. On my computer you have no sound till you either go out of reeaper and then switch back, or sometimes you have to cmpletely quit reaper and restart it. Tom is experiencing 'breaks in the sound'.
The text was updated successfully, but these errors were encountered: