Hi there.
I am in the process of setting up a room correction DSP based on LMS, squeezelite and CamillaDSP.
That's all done so far.
Now two key tasks are outstanding.
* impulse response recording
* filter generation
The idea is to use the streaming client for playing back the sweep and use another RPI
for the recording. I have a USB microphone at hand.
There's a huge problem that comes with this:
I meanwhile learned that splitting the playback and the recording device creates useless
data. There'll be a timing drift between both device clocks that messes up the impulse response.
However.
Not that long ago, REW introduced a feature called Timing Reference. The sweep signal
gets a reference chirp induced that'll make it possible to remove the timing drift of the recording.
So far so good.
I used to use and plan to use DRC-Fir for filter creation. The plan was to make the whole
project headless and fully scripted.
The issue. DRC-Fir doesn't provide a Timing Reference feature nor is it able to adjust the recording properly for preparing the impulse response. I posted a question over at DRC-Fir but didn't get an answer from Denis how he sees the topic.
Is anybody aware of a tool that could be used from commandline under Linux to generate an impulse response based on a Timing Reference method.
As a workaround I now can do the recording using the streaming client running a REW offline sweep. I then import the recording and create the impulse response within REW.
After that I export the response and create the filter with DRC-Fir on my Linux client.
That of course is a bit complex and can't be run by script.
Thx.
I am in the process of setting up a room correction DSP based on LMS, squeezelite and CamillaDSP.
That's all done so far.
Now two key tasks are outstanding.
* impulse response recording
* filter generation
The idea is to use the streaming client for playing back the sweep and use another RPI
for the recording. I have a USB microphone at hand.
There's a huge problem that comes with this:
I meanwhile learned that splitting the playback and the recording device creates useless
data. There'll be a timing drift between both device clocks that messes up the impulse response.
However.
Not that long ago, REW introduced a feature called Timing Reference. The sweep signal
gets a reference chirp induced that'll make it possible to remove the timing drift of the recording.
So far so good.
I used to use and plan to use DRC-Fir for filter creation. The plan was to make the whole
project headless and fully scripted.
The issue. DRC-Fir doesn't provide a Timing Reference feature nor is it able to adjust the recording properly for preparing the impulse response. I posted a question over at DRC-Fir but didn't get an answer from Denis how he sees the topic.
Is anybody aware of a tool that could be used from commandline under Linux to generate an impulse response based on a Timing Reference method.
As a workaround I now can do the recording using the streaming client running a REW offline sweep. I then import the recording and create the impulse response within REW.
After that I export the response and create the filter with DRC-Fir on my Linux client.
That of course is a bit complex and can't be run by script.
Thx.
Hey...
I really like the idea, pushing a buttom (script) and let the system generate and perhaps insert and engage a new fir filter on the fly. Makes comparing and listning comparing/test very effective.
I assume you read chapter 4.4 here (ofcause you did
) DRC: Digital Room Correction
Jesper.
I really like the idea, pushing a buttom (script) and let the system generate and perhaps insert and engage a new fir filter on the fly. Makes comparing and listning comparing/test very effective.
I assume you read chapter 4.4 here (ofcause you did
) DRC: Digital Room CorrectionJesper.
I'm not sure how precise you need the timing, but I have been working on this very issue. Using a Gstreamer based streaming system I can keep the system timing within about 0.5 to 1msec. More info here:
synchonized streaming to multiple clients/loudspeakers
FYI.
A related discussion over at ASR.
Or here @ REW hometurf.
And here's the discussion I started on the DRC-Fir-users Mailing List.
Dave from that group referred me to that ASR discussion.
We're talking micro seconds, a couple of samples, if you look at the graphs. Based on that the filters will be calculated.
It's IMO different than a "little" channel difference of a couple of milliseconds I'd say.
A related discussion over at ASR.
Or here @ REW hometurf.
And here's the discussion I started on the DRC-Fir-users Mailing List.
Dave from that group referred me to that ASR discussion.
We're talking micro seconds, a couple of samples, if you look at the graphs. Based on that the filters will be calculated.
It's IMO different than a "little" channel difference of a couple of milliseconds I'd say.
Your reading comprehension needs some improvement. I'm getting +/- 500 microseconds synchronicity, not a couple of milliseconds. Maybe it's all the same to you, but whatever. I was just trying to be helpful.
If the timing is so critical, why don't you just run a wire? This is in the same room, right? Why the need for two different clients?
Sorry. I misread your "micro" data. Your support is highly appreciated.
The serious room correction folks usually recommend to use a ProAudio Interface for combined playing and recording to not face the drift issue.
1.
That would require buying a ProAudio Interface and buying an analog microphone.
2.
That would require to tear apart my stereo "streaming" rig for running the exercise
3.
That would require to configure a complete new PRO audio interface
which is mostly Windows compliant only ( the offered class compilancy won't help
you much - been there done that )
4.
And then I'd run measurements on a different system, than the one I am listening to later
on.
Anything else ?
Now. There's a way out.
In 2019 these folks over at REW realized the drift issue and got it fixed.
Not sure for how many years people were using USB microphones and not being aware of the issue.
Anyhow. Great things happen. They found a solution. The whole subject got fixed by
introducing that timing reference method.
Everybody can use it this way now. There are no more drift issues if you record properly, if u use that method
USB microphones are basically no longer useless.
For REW: Case closed.
All I would like to do now. I want to do it all from commandline.
REW just allows to export the special sweep. This way I can put it on my LMS. And run it over the streaming client. I just can't post-process that sweep/inverse/recording without starting up REW on a PC later on. That's my issue.
In the end I'd like go from room to room with my microphone and battery driven and wireless RPI attached, push a button do the recording, calculate and apply the filters - all automatic - all by pushing a single button (as http request of course).
The serious room correction folks usually recommend to use a ProAudio Interface for combined playing and recording to not face the drift issue.
1.
That would require buying a ProAudio Interface and buying an analog microphone.
2.
That would require to tear apart my stereo "streaming" rig for running the exercise
3.
That would require to configure a complete new PRO audio interface
which is mostly Windows compliant only ( the offered class compilancy won't help
you much - been there done that )
4.
And then I'd run measurements on a different system, than the one I am listening to later
on.
Anything else ?
Now. There's a way out.
In 2019 these folks over at REW realized the drift issue and got it fixed.
Not sure for how many years people were using USB microphones and not being aware of the issue.
Anyhow. Great things happen. They found a solution. The whole subject got fixed by
introducing that timing reference method.
Everybody can use it this way now. There are no more drift issues if you record properly, if u use that method
USB microphones are basically no longer useless.
For REW: Case closed.
All I would like to do now. I want to do it all from commandline.
REW just allows to export the special sweep. This way I can put it on my LMS. And run it over the streaming client. I just can't post-process that sweep/inverse/recording without starting up REW on a PC later on. That's my issue.
In the end I'd like go from room to room with my microphone and battery driven and wireless RPI attached, push a button do the recording, calculate and apply the filters - all automatic - all by pushing a single button (as http request of course).
The python scripts posted in the ASR thread you point to already have what you need from the command line. They generate a log sweep with two short timing sweeps before and after said measurement sweep. They correlate to find the timing sweeps, calculate the steady state rate offset based on the time dilation/contraction of the interval between the sweeps and then resample the measurement to correct for this offset before correlating with the measurement sweep to produce the impulse response.
The impulse response is what the DRC-FIR program requires.
This doesn't use REW at all. In that same ASR thread the author of REW states that his correction for sample rate offset between playback and capture won't be available until the version after the version that is currently in pre-release.
So play the sweeps with the two timing references, capture them with your second device, then use the scripts to correct the sample rate offset and produce your impulse response.
The impulse response is what the DRC-FIR program requires.
This doesn't use REW at all. In that same ASR thread the author of REW states that his correction for sample rate offset between playback and capture won't be available until the version after the version that is currently in pre-release.
So play the sweeps with the two timing references, capture them with your second device, then use the scripts to correct the sample rate offset and produce your impulse response.
I just saw this as well: REW Questions | Page 2 | Audio Science Review (ASR) Forum
So REW puts one timing marker before the sweep, and one after. The script resamples to get back the original length. Nice and simple!
If you use the signals included in the dropbox link it should work right away, maybe it needs some modifications to use a sweep exported from REW (if the markers used by REW are different).
So REW puts one timing marker before the sweep, and one after. The script resamples to get back the original length. Nice and simple!
If you use the signals included in the dropbox link it should work right away, maybe it needs some modifications to use a sweep exported from REW (if the markers used by REW are different).
The sweep generated by the script has leading and trailing timing markers. REW only has a leading timing marker. So you're better off with the scripts and the associated files.
REW also doesn't apply microphone calibration when it exports impulse responses. Seems an odd choice but it is what it is. If you use DRC-FIR be sure to activate the microphone calibration stage if you have a calibration file for your microphone.
REW also doesn't apply microphone calibration when it exports impulse responses. Seems an odd choice but it is what it is. If you use DRC-FIR be sure to activate the microphone calibration stage if you have a calibration file for your microphone.
As above REW only uses one chirp at the beginning but there is now a clock adjust feature in the impulse tab, I've used it here with my good impulse to show how you can ruin it
As this is a manual adjustment it wouldn't help soundcheck with his idea of automation where the scripts above could.
I appreciate that getting another interface might be a pain but I don't think it has to be that expensive, having the playback and recording done by the same hardware device or at least clocked by the same hardware device is the best way to do it.
A used pro soundcard of a generation or more ago should be reasonably cheap.
Getting a good base measurement is really important to making good DRC filters anything that compromises that is a bad idea in my opinion.
As this is a manual adjustment it wouldn't help soundcheck with his idea of automation where the scripts above could.
I appreciate that getting another interface might be a pain but I don't think it has to be that expensive, having the playback and recording done by the same hardware device or at least clocked by the same hardware device is the best way to do it.
A used pro soundcard of a generation or more ago should be reasonably cheap.
Getting a good base measurement is really important to making good DRC filters anything that compromises that is a bad idea in my opinion.
Attachments
Hi there.
I talked to Dave last week, the guy who wrote the Python script, over at the DRC-Fir mailing list.
He's also using REW nowadays. The early scripts were used as prove-of-concept.
The scripts might still do the job.
Yep. Why not having a closer look at them and see if it fits the process.
@fluid
As far as I see while running the sweep, REW clearly shows (in the realtime graph ) that it runs two markers - leading & trailing. How would you count the sample drift without having two markers!?!?
I think it uses one chirp only if you've enabled the manual adjust. You then do not need
a second marker, right!?!?. You'd then manually adjust until the graph looks perfect.
I talked to Dave last week, the guy who wrote the Python script, over at the DRC-Fir mailing list.
He's also using REW nowadays. The early scripts were used as prove-of-concept.
The scripts might still do the job.
Yep. Why not having a closer look at them and see if it fits the process.
@fluid
As far as I see while running the sweep, REW clearly shows (in the realtime graph ) that it runs two markers - leading & trailing. How would you count the sample drift without having two markers!?!?
I think it uses one chirp only if you've enabled the manual adjust. You then do not need
a second marker, right!?!?. You'd then manually adjust until the graph looks perfect.
You're right that there is a second chirp at the end. I tested it just before I posted with a quick sweep and it is hard to hear. With a 1m sweep you can hear the chirp at the end much more closely.
I haven't got my system setup at the moment to test whether it actually does account for clock drift between measurements automatically. The manual adjustment might come in handy if anything automatic isn't getting the job done, which happens with REW sometimes.
I haven't got my system setup at the moment to test whether it actually does account for clock drift between measurements automatically. The manual adjustment might come in handy if anything automatic isn't getting the job done, which happens with REW sometimes.
Just thought about recording samplerates. REW lets you select them for the offline sweeps.
My new USB microphone, a Omnes Audio MikOne (individually 0°/90° calibrated and based on OMNITronic MM-2USB ) shows samplerates from 8 to 44.1 and 48kHz under Linux.
The datasheet doesn't state anything about supported samplerates.
I once read that the UMIK supports 48kHz only!?!?
That made me wonder how the MikOne microphone would handle all these offered samplerates. And if there'd be some kind of preferred rate.
(Sorry for my ignorance - havn't been using and looking into the whole USB Microphone subject until now )
My new USB microphone, a Omnes Audio MikOne (individually 0°/90° calibrated and based on OMNITronic MM-2USB ) shows samplerates from 8 to 44.1 and 48kHz under Linux.
The datasheet doesn't state anything about supported samplerates.
I once read that the UMIK supports 48kHz only!?!?
That made me wonder how the MikOne microphone would handle all these offered samplerates. And if there'd be some kind of preferred rate.
(Sorry for my ignorance - havn't been using and looking into the whole USB Microphone subject until now
)
Last edited:
This is what this thread is all about.
Getting around REW!
Though I'd be very surprised if REW would mess up the most basic task - generating an impulse response.
All I need it for, at least or now to get some quick results, is to provide the sweeps and the impulse response.
The rest is done by DRC-Fir.
There seem to be so many capable hackers and DRC folks around, that it should be possible to make sure that these Python scripts or some spinoffs deliver reliable results.
Getting around REW!
Though I'd be very surprised if REW would mess up the most basic task - generating an impulse response.
All I need it for, at least or now to get some quick results, is to provide the sweeps and the impulse response.
The rest is done by DRC-Fir.
There seem to be so many capable hackers and DRC folks around, that it should be possible to make sure that these Python scripts or some spinoffs deliver reliable results.
Just did the first RPI based offline recording.
Looks good as far as I can tell.
REW sucks great time under Linux (Fedora) though. E.g windows just won't refresh from time to time. It's really bumpy.
Another issue I figured out is that you'd need to reattach the audio devices to the PC to get REW to work properly. Loading calibration files asf. That tool wasn't developed with offline file processing in mind.
Yesterday I also learned that the REW exported impulse response won't have the microphone calibration embedded. That needs to be considered when calculating the filter.
Below the REW output outlines the drift if I am not mistaken.
Looks good as far as I can tell.
REW sucks great time under Linux (Fedora) though. E.g windows just won't refresh from time to time. It's really bumpy.
Another issue I figured out is that you'd need to reattach the audio devices to the PC to get REW to work properly. Loading calibration files asf. That tool wasn't developed with offline file processing in mind.
Yesterday I also learned that the REW exported impulse response won't have the microphone calibration embedded. That needs to be considered when calculating the filter.
Below the REW output outlines the drift if I am not mistaken.
Code:
Measurement generated from imported files
Stimulus:
REW-Sweep_20_to_20000_44k_PCM24_L_refL-m6dB.wav
Response:
DRC-recording-44100-24-m6dB-left.wav
Delay 0.1801 ms (62 mm, 2.43 in)
using estimated IR delay relative to Acoustic reference on sweep WAV file with no timing offsetI always get noisy, useless results that look like mismatched clocks. Since they were obviously bad, I never saved any. If I do any more, I'll save and post. My bad results came under Windows, I no longer run Linux. I could try with MacOS if I can find the USB adapters.
Pano: I have been using REW in linux for a few years, never had problems with access to audio devices. The java native code for alsa-lib is actually quite simple jdk/src/java.desktop/linux/native/libjsound at master * openjdk/jdk * GitHub . I have pushed it quite hard - e.g. 1.5MHz sample rate in a special build for testing https://www.diyaudio.com/forums/equ...t-samplerates-sw-analyzers-2.html#post6175436 .
I understand it is not an issue for you anymore but it would have deserved proper troubleshooting. I believe the problem could be sorted out.
I understand it is not an issue for you anymore but it would have deserved proper troubleshooting. I believe the problem could be sorted out.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.