zita-lrx jack module
Hello all,
Just to share an information, zita-lrx jack module has been integrated in the Ubuntu quantal distribution :
zita-lrx :A command line jack application providing 2, 3, or 4-band, 4th order crossover filters
Ubuntu ? Détails du paquet zita-lrx dans quantal
Linux + Jack + Jamin + zita-lrx + m-audio 1010LT = 30 band graphic EQ + 4 parametrics EQ + 4 way crossover
I'm waiting for a second hand 1010LT, should be at home next week 🙂
Zita-lrx - First release 05/01/2012
------------------------------------
Zita-lrx is a command line jack application providing 2, 3, or 4-band,
4th order crossover filters. The filter type is continuously variable
between Linkwitz-Riley (-6dB at the xover frequency) and Butterworth
(-3 dB at the xover frequency). Outputs are exactly phase matched in
the crossover regions.
The application supports up to 16 channels. This is a compile time
limit and easily changed, but if you have many channels it may be
a better idea to use two or more instances in order to spread the
load in an SMP system. Not that it would matter much - on my old
2 GHz P4, CPU load is around 0.6% per channel for four bands.
Configuration is by a text file using 'OSC' style syntax (similar
to Ambdec and Jconvolver). Apart from the basic filter parameters,
the following can be set:
- Channel labels (used for naming Jack ports).
- Frequency band names (used in output port names).
- Optional output autoconnections.
- For each channel: gain and delay (in ms).
- For each frequency band: gain and delay.
Hello all,
Just to share an information, zita-lrx jack module has been integrated in the Ubuntu quantal distribution :
zita-lrx :A command line jack application providing 2, 3, or 4-band, 4th order crossover filters
Ubuntu ? Détails du paquet zita-lrx dans quantal
Linux + Jack + Jamin + zita-lrx + m-audio 1010LT = 30 band graphic EQ + 4 parametrics EQ + 4 way crossover
I'm waiting for a second hand 1010LT, should be at home next week 🙂
Zita-lrx - First release 05/01/2012
------------------------------------
Zita-lrx is a command line jack application providing 2, 3, or 4-band,
4th order crossover filters. The filter type is continuously variable
between Linkwitz-Riley (-6dB at the xover frequency) and Butterworth
(-3 dB at the xover frequency). Outputs are exactly phase matched in
the crossover regions.
The application supports up to 16 channels. This is a compile time
limit and easily changed, but if you have many channels it may be
a better idea to use two or more instances in order to spread the
load in an SMP system. Not that it would matter much - on my old
2 GHz P4, CPU load is around 0.6% per channel for four bands.
Configuration is by a text file using 'OSC' style syntax (similar
to Ambdec and Jconvolver). Apart from the basic filter parameters,
the following can be set:
- Channel labels (used for naming Jack ports).
- Frequency band names (used in output port names).
- Optional output autoconnections.
- For each channel: gain and delay (in ms).
- For each frequency band: gain and delay.
Last edited:
Just received my 1010LT card last week and i've done few tests, results seems promissing. I'm using zita-lrx to cross my sub at 90hz in a 2.1 configuration. Just to get an idea of the product see below the jack connection from example1.zlr file configuration wich is part of the module.
Attachments
Openelec Frodo
The most recent release of this live Linux XBMC distribution has a new audio engine which is said to automatically stream bit perfect data to the DAC. It finds a Micromega MyDAC on USB easily enough and 'cat /proc/asound/MYDAC/stream0' confirms the sample rates are switching properly all the way to 192 kHz:
openelec:~ # cat /proc/asound/MYDAC/stream0
MICROMEGA MICROMEGA MYDAC at usb-0000:00:06.1-3, high speed : USB Audio
Playback:
Status: Running
Interface = 1
Altset = 1
Packet Size = 1024
Momentary freq = 192008 Hz (0x18.0040)
Feedback Format = 8.16
Packet Size = 0
Momentary freq = 192000 Hz (0x18.0000)
Interface 1
Altset 1
Format: S32_LE
Channels: 2
Endpoint: 1 OUT (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000
Data packet interval: 125 us
However it doesn’t display bit depth. XBMC's GUI can show the streaming rate, which for Redbook PCM is ~1.4M and 24/96 is ~4.5M, indicating the software recognizes the full 24 bits. I don’t know if that gets to the DAC. Do any command line gurus know if it's possible to display a stream's bit depth too? Thx in advance....
The most recent release of this live Linux XBMC distribution has a new audio engine which is said to automatically stream bit perfect data to the DAC. It finds a Micromega MyDAC on USB easily enough and 'cat /proc/asound/MYDAC/stream0' confirms the sample rates are switching properly all the way to 192 kHz:
openelec:~ # cat /proc/asound/MYDAC/stream0
MICROMEGA MICROMEGA MYDAC at usb-0000:00:06.1-3, high speed : USB Audio
Playback:
Status: Running
Interface = 1
Altset = 1
Packet Size = 1024
Momentary freq = 192008 Hz (0x18.0040)
Feedback Format = 8.16
Packet Size = 0
Momentary freq = 192000 Hz (0x18.0000)
Interface 1
Altset 1
Format: S32_LE
Channels: 2
Endpoint: 1 OUT (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000
Data packet interval: 125 us
However it doesn’t display bit depth. XBMC's GUI can show the streaming rate, which for Redbook PCM is ~1.4M and 24/96 is ~4.5M, indicating the software recognizes the full 24 bits. I don’t know if that gets to the DAC. Do any command line gurus know if it's possible to display a stream's bit depth too? Thx in advance....
Format: S32_LE
Your DAC receives 32bit samples. Your original 24bits are appended with one extra byte and the resultant 32bits are read by the USB controller.
Your DAC receives 32bit samples. Your original 24bits are appended with one extra byte and the resultant 32bits are read by the USB controller.
Format: S32_LE
Thanks phofman, I wondered about that. The new audio engine returns the same result with nothing playing so wasn't surre if it represents a description of the card's capablities:
Playback:
Status: Stop
Interface 1
Altset 1
Format: S32_LE
Channels: 2
Endpoint: 1 OUT (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000
Data packet interval: 125 us
Though I can't complain if it is....
Yes, that parameter describes the card capability. Some cards list two or more of them (e.g. S16_LE, S32_LE), in your case only 32bits are accepted. This is pretty much the most common value for 24bit-capable cards.
That means if the card is playing, it is receiving 32bit samples. Unless your chain decimates input samples to 16bits, you can be sure no information is lost. If you avoid dmix, rate plugin of alsa, and players which support 16bits only (such as old versions of mplayer), your chain keeps the bit depth.
That means if the card is playing, it is receiving 32bit samples. Unless your chain decimates input samples to 16bits, you can be sure no information is lost. If you avoid dmix, rate plugin of alsa, and players which support 16bits only (such as old versions of mplayer), your chain keeps the bit depth.
Thanks again phofman, I did not know that. As far as I can tell XBMC defaults PAPlayer to a do-nothing configuration so it looks like the system is running 'bit perfect' after all. Not bad for plug and play free software.
The new AudioEngine should be OK
e.g.
https://github.com/xbmc/xbmc/blob/master/xbmc/cores/AudioEngine/Sinks/AESinkALSA.cpp#L305
e.g.
https://github.com/xbmc/xbmc/blob/master/xbmc/cores/AudioEngine/Sinks/AESinkALSA.cpp#L305
Has anyone found a reliable passive crossover designer application in Linux?
I've never looked. There are so many online tools out there...
I've never looked. There are so many online tools out there...
I know I'm threadjacking a little now, but the online tools don't take into account a lot of factors. Impedance curves, frequency responses, phase, baffle-step, etc... A proper program takes these into account.
I know I'm threadjacking a little now, but the online tools don't take into account a lot of factors. Impedance curves, frequency responses, phase, baffle-step, etc... A proper program takes these into account.
Good point.
Have you tried any of the Windows tools in WINE?
WinISD runs in WINE fine, and I know it has some crossover calc functionality, but not sure if it covers all the bases you mentioned.
I suspect a lot of the tools would work under wine. And I know its not the best suggestion, but there always virualbox for those that don’t.
I've actually been trying almost everything I can under WINE, so far the only ones that open are ARTA tools, Speaker Workshop, and SOFMEA. I haven't tried WinISD as I've just been using the online version instead - maybe I should take a look at it in WINE to see the crossover options.
I really think this is an area we should put some development into on the Linux platform. I found a few old projects like gspeakers but they tend to be dead or dying.
I can't imagine it'd be fun to configure the audio drivers for my firewire soundcard through windows through virtualbox into jack and back.
I really think this is an area we should put some development into on the Linux platform. I found a few old projects like gspeakers but they tend to be dead or dying.
I can't imagine it'd be fun to configure the audio drivers for my firewire soundcard through windows through virtualbox into jack and back.
JFTR: WinISD Pro Alpha (0.50a7) works fine with wine-1.4.1, but it doesn't provide the features you're looking for.I haven't tried WinISD as I've just been using the online version instead - maybe I should take a look at it in WINE to see the crossover options.
Back on track for the moment-
Fun with Kernels. First, the Playback Designs needed another round of patches to get everything clean. Playback Designs sent a unit to Daniel Mack to sort it out and he nailed the details in a day. However it lead to an effort to create a specific data type for DSD in Linux. I don't think its an issue but in the future the host will be better able to communicate with the DACs instead of hiding the DSD inside PCM.
I also got the CMedia / Via patch working. It works well on the CM6631 demo board in all the modes I tried. It also works well with the Audio Widget and its standard firmware. The Tenor chip still has problems (its rate feedback is not standards compliant and it overshoots both ways radically).
If you have a kernel tree and know what you are doing the patches apply pretty easily. If you don't know what you are doing this is not a place to start.
Fun with Kernels. First, the Playback Designs needed another round of patches to get everything clean. Playback Designs sent a unit to Daniel Mack to sort it out and he nailed the details in a day. However it lead to an effort to create a specific data type for DSD in Linux. I don't think its an issue but in the future the host will be better able to communicate with the DACs instead of hiding the DSD inside PCM.
I also got the CMedia / Via patch working. It works well on the CM6631 demo board in all the modes I tried. It also works well with the Audio Widget and its standard firmware. The Tenor chip still has problems (its rate feedback is not standards compliant and it overshoots both ways radically).
If you have a kernel tree and know what you are doing the patches apply pretty easily. If you don't know what you are doing this is not a place to start.
Attachments
Hi there.
I'm trying to get the NAD M51 DAC ( a real nice DAC) for a friend of mine going
via USB.
It's shown under /proc/asound/cards
But there's no pcm device underneath.
aplay -l is not recognizing it either
At headfi I read a comment from last year May :
"NAD is using an extended UAC 2.0 interface descriptor"
that's why it is not working. Alsa wouldn't support that. I'm not sure about that.
Does anybody can get me a hint of how to approach the issue!?!?
Thx.
I'm trying to get the NAD M51 DAC ( a real nice DAC) for a friend of mine going
via USB.
It's shown under /proc/asound/cards
But there's no pcm device underneath.
aplay -l is not recognizing it either
At headfi I read a comment from last year May :
"NAD is using an extended UAC 2.0 interface descriptor"
that's why it is not working. Alsa wouldn't support that. I'm not sure about that.
Does anybody can get me a hint of how to approach the issue!?!?
Thx.
phofman.
THX a lot. That's an interesting one. As a matter of fact alsamixer didn't show anything either.
I recall some years back I added such a quirk for a different interface, just to make Alsa aware of the device.
Since Squeezebox Times , I havn't been fiddling around with Alsa a lot.
Doing a Alsa git compile might then lead to a solution. I have to reactivate my Alsa-upgrade script from years back. Or I'll look up in Ubuntu forums if somebody is maintaining it.
With squeezelite the Alsa fun seems to start over again. 😉
Cheers
IMO you need to upgrade to latest takashi's git, not to the older tarballs from alsa-project.org
Takashi: please help (compiling alsa-driver)
Takashi: please help (compiling alsa-driver)
- Status
- Not open for further replies.
- Home
- Source & Line
- PC Based
- Linux Audio the way to go!?