> From: Hermann Meyer <brummer-(a)web.de>
> To: linux-audio-user <linux-audio-user(a)lists.linuxaudio.org>
> Subject: [LAU] Which kernel do you use?
> Message-ID: <54C22928.2000704(a)web.de>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> I've get a new (used) mobo, and played with the kernel version to use.
> So far I've tested all from 3.19.0-rc5 down to 3.4.104
>
> Those, were rt-patches available I test as rt-kernel.
> Best results, I only get with the 3.4 series, all later kernels
> introduce Xruns here, sporadic, unrelated to the dsp load, even, when
> just jack is running.
> I build then all with the same configuration, play a bit with
> configurations deselect hyper-threading on the latest kernels, use
> threadedirqs, all to no avail. Only 3.4.xxx-rt kernel run absolute smooth.
> So, which kernels with witch configuration do you all use?
> <snip>
> Graphics: Card: NVIDIA GT216 [GeForce GT 220]
> bus-ID: 01:00.0 chip-ID: 10de:0a20
> Display Server: X.Org 1.16.1.901 drivers: nouveau (unloaded:
> fbdev,vesa)
>
I see you are using the nouveau driver for NVIDIA. Other RT users with
NVIDIA have commented on performance issues with nouveau and had better
performance with the NVIDIA akmods.
-- Jeff
Thanks Len for the useful feedback.
> In such a case, it would not be possible to add a WIFI that went to AP
> then snake then FOH mix then monitor as there would be close to 30ms. The
> WIFI would have to be a dirrect input to the FOH mix.
>
>
In reality of the 16ms latency I mentioned, 5.3ms are the A/D and 5.3ms are
the D/A (48khz, 2 periods of 128 samples in JACK at both sides). The
remainder approx. 5.3ms is buffering large enough to compensate for the
jittery behavior of network delay. In other words a packet needs reasonably
less than <5.3ms to fly from one end to the other. With an AP things are a
bit more delicate for the only reason that the packet must fly twice, i.e.
the transmitter must get access to the medium ASAP, and then the AP must
get access to the medium ASAP to relay the packet to the recipient. And
they must meet the deadline imposed by the receiver JACK cycle. Medium
access with 802.11 is the biggest issue in my experience. However, with an
AP it won't be 30ms, it will be much lower. Obviously a TDMA mechanism
would be much more useful for the transmission rather than the 802.11 MAC,
but improvements can be done. There is one AES paper from a guy in Finland
who managed to send 8channel audio at 192khz in packets of about 50samples
each, see http://www.aes.org/e-lib/browse.cfm?elib=16138
I will take a look again at the AES67 minimum requirements, I guess to
reach them a lot to development must be done. Basically the A/D and D/A
must be done with 2 ping-pong buffers of 32 samples at 48khz, and hope that
the network access and transport can be carried on reliably in 1.8ms.
Nothing you could do with a general purpose platform or OS at the moment,
but a good challenge for the future years.
Cheers,
Leonardo
Thanks Len for the useful feedback.
> I was going to say 10ms is about where I start to feel disconnected from
> what I am playing, but I realize I am thinking one way and round trip
> would be about 20ms. So 16ms might be well workable.
>
>
Psychoacoustic tests (many of them from the CCRMA SoundWire team and
others) shows that 21-25ms is acceptable to keep a steady tempo. Larger
values make the performers slow down, very low values make them accelerate!
AFAIK in musical instrument design the 10ms figure is taken as a threshold
for your instrument response (e.g. keypress --> sound), but in performance
the values can be higher as said.
Your inputs are interesting, and yes, I think AES67 could be the first step
towards integration.
More soon...
Leonardo
Hi list, I have a Kurzweil K2000R synth and a scsi zip 100 drive. I'd
like to be able to download files from the web and transfer to the
synth. I found a USB Zip 100 drive available which I'd like to connect
to my Linux PC so that I can transfer the disks across to the scsi
drive on the K2000.
The USB drive is here:
http://produto.mercadolivre.com.br/MLB-621544980-zip-drive-iomega-zerado-co…
Does anyone know if this will work? Will I have any trouble with this
drive on Linux working with K2000 formatted disks?
Thanks,
Just to bring the discussion back to its original topic, I see and know
already that audio over 802.11 is always thought of as a geek thing when
not an insanity, but at my institution we felt this as good challenge for
engineering research and I've been working on that as part of my PhD
studies in the last two years. Updates and material about the project are
reported at our research group webpage
http://a3lab.dii.univpm.it/research/wemust
The project, called WeMUST, i.e. wireless music studio, was started to test
current network technologies in a *studio*, but later we also addressed
live stage usage and a concert was performed last summer on the sea. In
that case we acquired signal with Debian-based ARM platforms (beagleboard
xm) and sent it to special devices from Mikrotik through Ethernet. The
Mikrotik devices have directional antennas and created 802.11a bridges from
sea to land. The networking topology allowed for monitoring and the
round-trip latency allowed by the system was 16ms at lowest (but could be
reduced with a different HW choice). The musicians could synchronize well
and all had the same latency, imposed by JACK, running on both the ARM and
the PC mixing the signal on the land.
To recap, my opinion is that 802.11 can be as good as any other wireless
technology in providing music and compared to legacy analog techniques the
quality is not compromised (unless the link is so bad that connection
breaks/packets get lost). Of course the 802.11 family of protocols is
mainly targeted at throughput and best effort delivery, this is why the
audio community must demand for amendments that allow a robust audio link,
instead of neglecting the opportunity and relegating wireless connectivity
to a marketing feature (as it is up to know, just a gimmick for product
brochures to boost sales, showing ultra-cool ipad apps for remote control
and nothing more).
With this I don't mean saying that we should replace affordable and
reliable audio cables with ultra-expensive wireless stuff. My goal, as a
researcher is to thrive into the technical and usability challenges of a
technology so widespread nowadays, show what can be done and check from the
industry or the potential users if there are new applications that are
opened by wireless and most importantly networking.
Networking is a key aspect, indeed, because a point-to-point link is not
novel, but if wireless connectivity can provide integration of
functionalities and devices at low extra cost, it is worth investigating,
IMO, at least at the academic level.
Cheers,
Leonardo
No I am not asking if audio over WIFI is a good idea :)
But I thought some might be interested in this:
https://www.kickstarter.com/projects/432967670/jack-the-wifi-guitar-cable
I note that the actually latency as a number is not mentioned anywhere.
There are this many times shorter than something else kinds of things, but
not a number of ms from end to end.
They suggest that they have "a total re-engineering of Wi-Fi to suit real
time audio" yet at the same time they managed to "keep it compatible with
existing devices meaning no changes to your PC or mobile device."
BTW, Linux is not mentioned anywhere and neither is open (source or
otherwise). However, I posted this because someone was asking about
running a few more audio lines wirelessly and the common thought is that
it can't be done with reasonable latency for monitoring. These people seem
to think it can. They are talking compatible with a wide range of devices
(android included) so the drivers are not being redone either.
Auto-seeking low traffic wifi channels might be a part of it, but from
what I have seen, scanning channels takes more time than anyone wants for
a gap in audio.
--
Len Ovens
www.ovenwerks.net
On Sat, Jan 3, 2015 at 1:12 PM, Albert Graef <aggraef(a)gmail.com> wrote:
> Linux Audio Conference 2015 - Call for Participation
Another quick follow-up with the latest news and bits of information
about the upcoming LAC 2015:
Our friends at Grame recently initiated their first Faust Open-Source
Software Competition. The results will be announced during LAC 2015.
The submission deadline for the competition is March 15, 2015; the
winning software will receive a 2000 Euro prize. Please check
http://faust.grame.fr/index.php/component/content/article/7-news/82-faustaw…
for details.
MOD (http://www.portalmod.com/) will sponsor the Linux Sound Night at
LAC 2015, which will take place on Sat, April 11 10 pm at the "Baron"
on the university campus. Our thanks go to the MOD team for their
support! LAC 2015 is mostly publicly funded, and registration and
admittance to the conference is free (gratis). Hence our resources are
limited and support by private, public and corporate sponsors is much
appreciated.
Finally, a friendly reminder that the LAC 2015 deadline for all
submission types is approaching: February 1st. Your contributions make
the conference what it is, so please check
http://lac.linuxaudio.org/2015/participation for more information and
links to our online submission system. Note that as usual we have
created two different OpenConf instances: one for the submission of
regular papers, lightning talks and poster sessions, and a second one
for music, installations and workshop proposals. If you have any
questions concerning your submission, please don't hesitate to contact
us at lac -at- linuxaudio.org, or through our #lac2015 irc channel on
freenode.
Sincerely,
The LAC 2015 Organizing Team
--
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email: aggraef(a)gmail.com
WWW: https://plus.google.com/+AlbertGraef
Hello
I am an Ubuntu 12.04 user in an 7yr old laptop.
At this moment I urge a hardware improvement for my work which is: sound
synthesis and processing controlled by external data via USB (kinect sensor
and customa arduino based sensors) and WiFi (osc data).
So i have to make an investment in a powerful laptop with the proper
configuration for my needs which could be translated into:
* very powerful processor for the dsp algorithms
* 3+ usb ports (not hubs) so i can connect the external sensors and an
external soundcard
* a good wireless card that would not use any resources from the main
processor
* a video card that would not interfere with the main processor
Although I think i know the basic needs, I can not name the manufacturers
or models of the processor, board, video and wireless card that would make
my system work the best.
It would be of great help if you could help me choose these elements based
on your positive experience on any of them and even more it would be great
if you could recommend a specific commercial laptop that could have these
features/elements already packed.
Thanks for your help
Daniel