Good suggestion! I changed the two file permissions and tried ecasound 2 channel. I got the same result with -i:alsahw,1,0,0, BUT with -i:/data/music_file.wav I had filters running. That confirms that -i: input from ALSA remains a problem. No additional progress with initiating the FIR system from a SoX stream into alsa.
What happens if you use ACDf on 2 channel audio instead of LADSPA_FIR, direct audio I/O through alsa via -i:alsahw:, etc when using ecasound? Does that generate an error? We know that ACDf works on your system, so testing that scenario would help to sort out whether the problem lies with the system configuration (e.g. because it is root accont only, permissions related, etc) or with the LADSPA_FIR plugin itself.
Verrry interesting! I added 'root' to the group named 'audio'. Then, using a terminal from my desktop rather than laptop,
1. ACDf filters ran in ecasound using two channel mode. No surprise.
2. Then, I again tried LADSPA-FIR with just the filter parameters pasted into the previous ACDf command (using the terminal up arrow). It ran!
so... How about 6 channels? This time I used backslashes instead of one run-on command line. dun dun dunnnnn...
3. It ran! Your work is done here! 🙂
The alsa LADSPA_FIR plugs still fritz-out. I'll play with ALSA later because I now need to pay some serious attention to a large out-of-town 'honey-dew' project.
Many thanks, Charlie!
1. ACDf filters ran in ecasound using two channel mode. No surprise.
2. Then, I again tried LADSPA-FIR with just the filter parameters pasted into the previous ACDf command (using the terminal up arrow). It ran!
so... How about 6 channels? This time I used backslashes instead of one run-on command line. dun dun dunnnnn...
3. It ran! Your work is done here! 🙂
The alsa LADSPA_FIR plugs still fritz-out. I'll play with ALSA later because I now need to pay some serious attention to a large out-of-town 'honey-dew' project.
Many thanks, Charlie!
Glad that you have this working now. So now that we have worked through some of the issues I would like to make some changes/updates to the FIR package. For starters, perhaps there is no real need to point the code to the filter table and FIR engine via environmental parameters, but as you francolargo have done instead just hard code it into the source before compiling. It is not likely that the locations for these files would change often or ever, and it would be a simple matter to put a literal string containing the filepaths at the top of the code and then direct the user to modify to reflect where the files will be located on their system. In additino to that I will remove those lines regarding Wisdom or make it optional, or allow the code to check for Wisdom and then just fall back to estimation like it does not for FFTW.
What else might I change?
First off, thanks again for sharing this significant body of work!
1. I'm not sure that changing to hard-coded table and engine paths is any better than using environment variables, unless it expands the range of hosts. It did solve one problem within the ALSA plugs, but there is more to understand and fix. [My own desire to use the plugs within ALSA is based on my particular hardware. The McASP serial cores in the AM3358 allow external clock input, and that allows my system to swap the clocks creating I2S based on the original PCM file sample rate. I can read that original sample rate and redirect the "bit perfect" I2S to alsa ladspa_fir plugs with frequency-correct filter coefficients. Not sure how much delay that might cause...]
2. I personally need to push the boundaries within ecasound. For example, I'm not yet sure I need to use a loop, and I thought the FIR period reports seemed long for the size of my filters. Also, I wonder if functionality built into the 'server' portion of ecasound might allow for filter set substitution. That will take some study.
3. While expanding technical possibilities is rewarding, I'm unsure if my rig has the horsepower to make the best use of all the power provided by FIR filters. So its finding the balance between 'could' and 'should'. That will take time to sort out.
4. For me, at least, this is a perfect spot to just start listening and trying different filters. But again, I'll also be taking a necessary break as well.
Cheers,
Frank
1. I'm not sure that changing to hard-coded table and engine paths is any better than using environment variables, unless it expands the range of hosts. It did solve one problem within the ALSA plugs, but there is more to understand and fix. [My own desire to use the plugs within ALSA is based on my particular hardware. The McASP serial cores in the AM3358 allow external clock input, and that allows my system to swap the clocks creating I2S based on the original PCM file sample rate. I can read that original sample rate and redirect the "bit perfect" I2S to alsa ladspa_fir plugs with frequency-correct filter coefficients. Not sure how much delay that might cause...]
2. I personally need to push the boundaries within ecasound. For example, I'm not yet sure I need to use a loop, and I thought the FIR period reports seemed long for the size of my filters. Also, I wonder if functionality built into the 'server' portion of ecasound might allow for filter set substitution. That will take some study.
3. While expanding technical possibilities is rewarding, I'm unsure if my rig has the horsepower to make the best use of all the power provided by FIR filters. So its finding the balance between 'could' and 'should'. That will take time to sort out.
4. For me, at least, this is a perfect spot to just start listening and trying different filters. But again, I'll also be taking a necessary break as well.
Cheers,
Frank
Ah, that sounds like a cool project.
When processing FIR filters in software like this you will have two delays. There is one delay that is embodied in the filter kernel due to the requirement that it cannot appear at the start (e.g. due to some amount of pre-ringing required, etc.) and the difference between where the impulse peak and the start of the filter kernel is the delay. Then there is the processing delay(s). This includes I/O, scheduling, and for my plugin the time it takes for data to be sent to the FIR engine, the engine to process it (perform the FFT operations), and then return it to the plugin. It is these last three that are reported in the "cycle time" by my plugin so that you can know what it is and fix it to some predetermined value. Keep in mind that some of the other latencies are also present when processing IIR filters in software. If latency is important then I would just stick with hardware based FIR DSP or you could try out an FIR filter engine that does partitioned convolution (CamillaDSP does this for example) which still has some FIR processing latency but it is relatively small.
No problem. Just thought I should ask about it while I am under the hood. FIR does require some higher CPU capabilites compared to IIR filtering, so your current platform might not be up to the task.
@CharlieLaub I didn't know where else to ask this, but in "ACDf_usage_notes.txt" the ACDf input parameters are listed like this:
Whereas almost every example I've seen in this thread follows the order [type polarity dB ....]. Is this a typo in the .txt or am I missing something else? Apologies if this has been answered before 🙂
@themonarc
The order of the parameters is important when using ecasound. It should be type, polarity, dB,...
What actually determines this in my code is this (starting on line 48):
It looks like I reversed dB and polarity in that doc. I haven't used ecasound for a few years now, so I never caught the mistake. Thanks for pointing it out. I will update the file and repost to my website in the next couple of days.
The order of the parameters is important when using ecasound. It should be type, polarity, dB,...
What actually determines this in my code is this (starting on line 48):
C++:
//order of parameters:
#define ACDf_TYPE 0
#define ACDf_POLARITY 1
#define ACDf_GAIN 2
#define ACDf_FP 3
#define ACDf_QP 4
#define ACDf_FZ 5
#define ACDf_QZ 6
#define ACDf_INPUT 7
#define ACDf_OUTPUT 8It looks like I reversed dB and polarity in that doc. I haven't used ecasound for a few years now, so I never caught the mistake. Thanks for pointing it out. I will update the file and repost to my website in the next couple of days.
Great, peeking at the the Cpp is exactly how I troubleshooted last night to get my filters working.
Note that there are other parts of the .txt that use the wrong order (which may or may not be a big deal) e.g.
Thank you for your work, my speakers never sounded better! Hopefully this little documentation fix will help future users that stumble upon this project.
Note that there are other parts of the .txt that use the wrong order (which may or may not be a big deal) e.g.
Code:
ACDf filter types and their required parameters:
TYPE DESCRIPTION REQUIRED PARAMETERS
0 gain block db, polarity
1 1st order LP db, polarity, fp
Code:
The following table lists the default values:
PARAMETER DEFAULT VALUE
type 0 (gain block)
dB 0 (no gain or cut)
polarity 1 (normal polarity)
...Thank you for your work, my speakers never sounded better! Hopefully this little documentation fix will help future users that stumble upon this project.
@themonarc
I finally got around to correcting the documentation and updating the files on my web host. Thanks again for bringing that to my attention! Good luck with you projects.
I finally got around to correcting the documentation and updating the files on my web host. Thanks again for bringing that to my attention! Good luck with you projects.
Excellent! Thanks for doing that.
Just so you know, when I now try to download the ACDf .tar, I get a 404 page like below. Maybe this is just a temporary issue but I figured I'd tell you.
@themonarc
I changed the file name to reflect the update. You probably need to clear your browser cache or refresh the page. The new file name has "v3.01" in it.
I changed the file name to reflect the update. You probably need to clear your browser cache or refresh the page. The new file name has "v3.01" in it.