Fallowing up the long discussion i'm trying to sort of give the
information you all seem to be missing.
there was a meantion of this, but not too many of you have paid any
here you can find an article about the current status of the protocol mess:
http://prosoundnewseurope.com/pdf/PSNLive/PSNLive_2009.pdf (page 28)
obviously eas50 is good to go, but Ethernet AVB is right thing really.
the only thing that it's still work in progress, but many of the
proprietary vendors, which already have their own networking solution
(like Harman with HiQ-net, the one i can name of top of my head)
are involved in AVB stadard deveelopment.
The idea of AVB is to bypass the IP layer, which is right thing really.
you don't need to assign IPs to your audio nodes, really!
in avb you'd just have to select channels that nodes whant to listen to.
there is a fair bit of documentation on the ietf.org AVB group's page.
but XMOS is looking to be the best point of refference:
is think we should forget everything else and crack on with the XS1 AVB
their XS1 chips seem to be really great,
their are basically every innovative and open-source minded.
the official toolchain is LLVM-GCC based.
you can use C, C++ or their own XC.
XC is basically C with some stuff omited (like goto and floats)
and XMOS IO stuff added, don't just say WTF, look at it first!
you should also watch the videos here:
especialy the two about the "XMOS Architecture" and the AVB
some dev-kits are quite expencive, but that's due to low-volume really
there is alos a nice USB Audio kit!
plus there is alittle board that is cheap and has two RJ45's on it
I'm myself studying the XC book at the moment. And geting familiar with
the tool set :)~~
looks very exciting, cause these are the invovative chips!
ok, may be an FPU is really missing on XCore, but how many DSPs have
it anyway? well quite a few, but there was no FPU on dsps for ages! :))
also XC or C/C++ are so much more obvious then the bloody "menthal american military engeneers non-sense" called HDL-whatever!
Hope you will appreciate my excitment :)~ (l0l)
I managed to get SuperCollider and JACK running on my IGEP , on the pre-
configured Ubuntu on the SD, but of course the audio is still bumpy.
So... I'm looking for a RT kernel for this little machine... Anyone have any
I did find this one: http://beagleboard.org/project/omap-rt-patch/
but the project doesn't show much recent activity.
and... I also noticed that JACK didn't want to run with alsa as backend; oss
as backend works though (but gives the bumpy sound).
Anyone willing to share their experiences doing linux audio on ARM processors?
I'm a recovering audiophile. When i was reading the magazines and
reading about over priced (in my now opinion) speakers, the words "full
range" tended to mean that a speaker was reasonably flat from 20 Hz to
20 kHz. Granted those were unusual.
I have read that speakers in an ambisonic set up should be "full range".
I'd like to set up a ambisonic speaker system (8 channel to start), and
the prospect of 8 full range channels is daunting. Since it seems they
would be stand or wall mounted (at least some of them) that means
monitors and subwoofers. Since all channels must be the same, that means
8 subwoofers...somewhere in the room.
So what does "full range" mean usually and what does it mean in terms of
talk on this list?
I am very much new to Linux and Linux audio. I am trying to measure audio
IO latency for my system.
Jdelay seems to be the right tool but when I run it on the terminal, I am
getting message "Signal below threshold..." which probably might be because
Jack is trying to capture audio and ends up getting the low noise floor
because I do not have meaningful signal source connected. But then I tried
to patch the this App to the qJACKctl app but the settings console is
not straight forward to interpret. as it involved many parameters.
I guess there are # of frames per period that may eventually be used
to calculate the target latency but *is there a step-by step document
description for Jdelay and any other JACK tools and also using JACK audio
server in an effective manner*? Also, qJACKctl console does not offer
options for very low sampling rates like 8 KHz. With ALSA, this should be
possible but may be this particular tool does not support it. Can anyone
[trimmed down reply-to linux-audio-dev(a)lists.linuxaudio.org]
On Tue, Jul 27, 2010 at 8:25 AM, john ffitch <jpff> wrote:
> Any chance of an option to envy24control to allow colour blind people
> to see three zones? I had been using it for years before I was told
> that there is a red section at the top and green below
> ==John ffitch
Thank you for writing and you'll be happy to know that the new
"mutida24" (to avoid confusion with the old and overly colorful
envy24contol) does not use coloration in the same way, and yes, I'd
imagine the old choice of colors would be particularly bad for
Although there's been some recent minor changes, this is the look of
the new meters:
Hopefully, at least for any colors at issue, there is enough contrast
against the background to make it properly visible. Please let me know
of any specific issues w/ the simplified, and more X-efficient meters
in this version, which try to be less eye-candy, and more useful for
making a visual level determination of inputs, outputs, or digital
The peak metering features a green/white/orange/red progression of the
peak color (the thin band that stays fixed while the meter below
bounces around). But in
addition, and more helpful to you, are he peak-level readouts in dBFS
from -48 to 0dBFS for all inputs and outputs, including in the "Analog
Volume" panel. The 0dBFS label is red with white background, whereas
the other levels remain black with white background. That should
provide enough redundancy in the metering to not hide important
information from you. However, I'm not sure of the perceptibility, of
the red "0dBFS" marking. On the other hand, it does say "0dBFS" (in
red) which is quite different-looking than, say "-5.02" (in black)
the green (at 0dB) and red (+6 +12 +18) markings on the ADC would not
be very useful for you; fortunately, the "+" should be visually
distinctive from all the other "-" markings in blue. Other
alternatives would be Bolding amplification values, and underlining
Jörn Nettingsmeier wrote:
>> it's no problem (and in fact customary) to use subwoofers with
>> ambisonics for low-range extension. you can either forego localisation
>> in that band and just use a mono sub (perfectly ok), use 2 and have some
>> l/r signal in ithem, or you can use 4 subs in the corners of the room
>> and drive them with a special horizontal decode.
For subwoofers (but not main speakers) you
can also use three. To see the various options
discussed in more detail, visit:
Martin J Leese
E-mail: martin.leese stanfordalumni.org
This might be a complete offtopic here, but there hardly is another
place to ask, where there are serious audio-tech savvy people. :)
So I have Creative Audigy 4 sound card on WinXP x64. It's been a pain to
set-up a working 5.1 surround system. In fact I've never done it.
Has anyone got it right?
I had no luck with Linux' ALSA either.
I currently run it with the bloody Creative's CMSS, which is pretty good
for stereo music recordings and most movies.
I knew my 5.1 wasn't right, but until I tried ambisonics I was quite
oblivious to the fact.
So the actual problem.
There is no real surround. The back speakers actually put out the same
thing as front, with, what appears to be, some phase offset. This is
most likely CMSS doing, but If I disable CMSS I get ouput only of two
front speakers. Regardless of CMSS setting anything that is recorded as
in "directly behind" doesn't play at all.
With Linux and ALSA, there is a bit different problem. ALSA appears to
cap the maximum amplitude below capability of the sound card, so I get
"clipping artefacts" at *much* lower volumes than WinXP.
So neither ALSA driver, nor music players were satisfactory to me and I
never went though pains to get surround on it.
I had not tried my luck with OSS4 yet. If it was up to me I'd use
stripped down OSS4, which would provide direct access to 6-channel
output. On top of it I'd put JACK and then route what I want, where I
want. This is no small task however, and I'm not even sure if it can be
done at all.
I ask of you to share any experiences and ideas you have with Audigy, on
any of these platforms.
Thanks in advance!