So you say, each time you start playback this might introduce a different fixed delay between two cards? Well, I pretty much can't recommend that anyways, to repeat myself once mor - get a multi-channel soundcard or i2s interface (if you want to use your own DACs). These are readily available.
I'll use my RME audio interface from my studio system to get me it has more than enough analogue outputs
I cant wait to start playing
The alsa multi plugin splits the multichannel stream to individual RAM buffers for each soundcard. But I do not think there is any way the drivers can tell the two devices to start their DMA transfers at the very same moment. Plus each device has a small FIFO between the incoming stream supplied by DMA and outgoing stream to the DAC clocked by the synced clock. There is no way to tell the two soundcards to start outputting these internal FIFOs at the very same moment.
A multichannel card reads whole frame (i.e. all channels) in the same DMA transfer, samples for each channel are held together all the way to I2S.
A multichannel card reads whole frame (i.e. all channels) in the same DMA transfer, samples for each channel are held together all the way to I2S.
I have not done any analysis of the delay between the multi plugin slaves, but IMO the start code is alsa-lib/pcm_multi.c at master * tiwai/alsa-lib * GitHub - slaves are started in a loop.
This is quite interesting! That function checks for some "linked" attribute on the pcm, and if it's true, then it only starts the first one. Do you know what that linked thing is?
I tried this out of curiosity and I can confirm it drifts like hell, i could literally hear around a seconds worth of delay between the primary speakers on one interface and the sub on another interface.
If i play one track they both start at the same time, but if I skip or pause then play one interface starts much later than the other and you can hear it all over the place.
Obviously the specific time difference depends on the interface combination being used, but it's definitely not usable with multiple interfaces.
That being said, I'm very impressed with the results, I had this running perfectly with the interface I borrowed from my studio system. I had a basic 2.1 set up going using a HPF and LPF, I added some EQ as well and I was really impressed with the results.
I've ordered a used Xonar U7 (because it was only £40) so I can take my studio interface back. I'm going to use this software as part of my permanent set up.
Do you have any suggestions about how I might EQ correct for my sub?
I can take measurements with a calibrated mic and use REW (Room EQ Wizard software) to measure the peaks and troughs say below 100hz created by the subs interaction with the room. But is there a way to import this into your software to apply a correction EQ?
I'm aware this can be done with the miniDSP.
Thanks for pointing me in the direction of this software, it's a gamechanger for me, and saved me money from going down the MiniDSP route.
I'll keep posting my progress and feedback as I integrate it into my main set up.
Last edited:
Several seconds are way too much (many magnitudes), there must be something setup wrongly.
Devices linked by the alsa multi plugin are started/stopped/forwarded in one for loop, the difference should be just a few samples at most, IMO less. Such setup has been used for years e.g. https://web.archive.org/web/20121128174643/http://quicktoots.linux-audio.com/toots/el-cheapo/
Devices linked by the alsa multi plugin are started/stopped/forwarded in one for loop, the difference should be just a few samples at most, IMO less. Such setup has been used for years e.g. https://web.archive.org/web/20121128174643/http://quicktoots.linux-audio.com/toots/el-cheapo/
It was up to a single second, not several seconds, sorry if i hadn't made that clear.
You shouldn't show me things like that, I've only just got my latest amp build off my desk, I dont need another DIY thing to try
My current focus is to get the listening room setup finalised.
One question, I'm relatively new to Linux, how do i set the bit depth and sample rate of my interface in Linux?
Last edited:
PAXOR can show and work with an FRD file. There will then be three curves.. the *.frd, the filter response and the (combined) result. One basic approach could aim for a flat result curve by applying filters.
Further to this, in creating the reference file you will probably take multiple spatial measurements for sub usage and average them somewhere else.
You may also come to the decision to use further EQ, which you can either combine into the final reference curve, or apply independently. You can use a screen trace to capture a result and make a further target.
If you want to separate your standard EQ from crossing, you can cross blind after combining the standard rolloffs with your target file, but don't do this for higher Q effects for accuracy.
You'll want to confirm phase/timing later using separate measurements.
I can't confirm this for the playback side. I only did this over years back when joining two ICE1212 soundcards for a recording setup. But we never used it for playback, just for recording. Using JACK back then. And the latency difference between two cards _when recording_ wasn't noticeably. Good enough for me back then...
I'll look for that tonight.
I did see on stack overflow changing the config file was mentioned, then there were conflicting responses saying that wasn't correct in new versions of Ubuntu, the tread seemed to descend into an argument, which was confusing for a linux noob like me.
Thanks mate, I'll check it out and look for the appropriate settings.
I did see on stack overflow changing the config file was mentioned, then there were conflicting responses saying that wasn't correct in new versions of Ubuntu, the tread seemed to descend into an argument, which was confusing for a linux noob like me.
Thanks mate, I'll check it out and look for the appropriate settings.
First I should say I'm on Debian.
These arguments might be for one of two reasons. Either there is a problem you need to avoid... or both ways will work but only one is proper/tidy/elegant. Not to sound dismissive, it is best to learn to do things right, but on the other hand you still need to learn and try things.
These arguments might be for one of two reasons. Either there is a problem you need to avoid... or both ways will work but only one is proper/tidy/elegant. Not to sound dismissive, it is best to learn to do things right, but on the other hand you still need to learn and try things.
Last edited:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.