Linux Audio the way to go!?

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
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.
 
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.

attachment.php
 

Attachments

  • Capture du 2013-04-05 20_02_42.png
    Capture du 2013-04-05 20_02_42.png
    68.6 KB · Views: 575
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....
 
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.
 
Member
Joined 2011
Paid Member
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'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.
 
Member
Joined 2004
Paid Member
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.
 

Attachments

  • Playback Designs & CM6631 patches.zip
    3.1 KB · Views: 48
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.
 

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
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.