I'll just say this one last time in a separate thread and close the topic
once and for all, because it makes me feel like a complaining old man.
I know many of you use soundcloud to share and distribute your material,
and I certainly can understand why, since SC seems to offer a very
convenient platform to do so and facilitate exposure and feedback from
others. No trouble there; maybe I'll jump on board the soundcloud train
if and when I ever have any audio worth sharing.
Now, as you all know, soundcloud uses a flash-based player and does not
seem to allow direct download by default. As a result, should I wish to
sample material posted on soundcloud I need to 1) fire up GNOME, 2) fire
up Orca, 3) fire up iceweasel, 4) memorise and copy the URL, 5) plug
some headphones in my computer's on-board sound interface, because audio
doesn't play through my main JACK setup, 6) wrestle with the partially
accessible SC flash player. This is my personal experience, but I know
from previous threads that other users on this list face at least some
of the same issues. I therefore think many on this list would be more
likely to comment on shared material if direct links were provided or
if, at least, direct download were enabled on soundcloud.
Most of you have amazing material to share: please don't lock yourselves
into a platform!
All right, I rest my case.
Happy Halloween to all!
Over the summer, I set up a Linux server running Airtime for a small micropower radio station in a remote area.
All went well, except now I'm getting reports that the audio is stuttering endlessly on one 40ms frame of audio, like a CD skipping. The only way to get it to stop is to restart the liquidsoap playout engine (or to power-cycle the server, which is what they are doing now whenever it chokes). This seems totally wrong to me, but that's how it is.
I've heard audio stutter briefly on machines, usually under heavy CPU load, but what could be causing it to stutter endlessly (until the application quits), on one frame with low/no load?
What could be done to stop it from doing that?
For reference, this is a 3Ghz P4, running airtime 2.1.2 which uses liquidsoap 1.0.0-svn, with Ubuntu 10.04 and kernel 2.6.32-38-generic-pae, hyperthreading on, 2GB RAM, 126.96.36.199+dfsg-0ubuntu3, and the liquidsoap instance runs typically 3-10% of CPU. I've looked in the logs at the time the error occurs, and.... nothing. Nothing at all out of the ordinary in the (noisy) airtime logs or the system logs.
Because it's a remote server and I'm not on-site, I'm not interested in superstition: "try this, maybe it'll help, try upgrading to the latest version of x, y, z, try random-endless-variations". That-- and shrugs-- is all I've gotten from Airtime and Liquidsoap.
I'd like to know exactly HOW this problem is occurring and what can be done to fix it permanently. I figured if anyone might have some clues where I could look to find this out, and what mechanism could possibly cause a single frame of audio to stutter endlessy, I might find some here. Thanks.
some time ago i sampled a vintage rhythmbox (the Denon CRB 90) and created
a hydrogen drumkit with these samples
being the good civilian i am i decided to try and contact Denon and
politely ask them if i could use these samples (and if possible release the
drumkit under some sort of CC license)
the answer i got was this :
uhu : nada, nothing, null, etc ...
so i figured if they dont allow me to use the samples ... why dont you guys
no seriously, does anyone know if i can use the samples -without going to
jail and all-
the box is really old (see
so i was wondering if there is a limitation on the time that samples are
'protected' by a license
any ideas ?
follow me on my Audio & Linux blog <http://audio-and-linux.blogspot.com/> !
Does anyone know whats going on with pulseaudio-module-jackdbus in Debian
On my system the jackdbus module doesn't exist in the repos and the result
is that pulseaudio doesn't play nice with jack.
I can see that jackd2 was compiled with dbus support so not sure what's
going on with the missing pulse module.
Boost Hardware Ltd
Has anyone else had this problem? For some pieces using live mic input, I
wanted to reduce latency by pulling the Jack IO buffer size down to 512
samples from the default 1024. (I also tried 256 samples, but that just
made Jack crash.)
But with the smaller buffer, the mic gets an additional 30-40 dB of gain,
making the input unusable. If I turn the preamp on the fast track down very
very low and speak quietly into the mic, the sound comes through without
obvious distortion or glitches, so it doesn't seem to be an xrun thing. But
it distorts very easily and very badly.
If I switch back to 1024 samples, the problem disappears.
Why would the driver's buffer size have an impact on the incoming signal's
I guess that the one or the other Linux user still like to try the oe or
the other windows application from time to time, without the need to
install a VM, so it could be of some interest that CodeWeavers Inc.
gives away a free copy of CrossOver today, 31.10.12
So a friend of mine at work has decided she wants to check out audio and
MIDI on Linux. BUT, she has a Macbook Pro, and I've never paid any
attention to distros that were for Macs. What's a good audio/MIDI (plus
general purpose) distro that is easy to get running on a Macbook Pro?
Rather long time since I posted on this list now. Some of you may recognize
me as "zth" on IRC. =)
I've been working on a little project this summer/fall, which I'm kind of
finishing up now. It will be some sort of blend of hiphop/pop/acoustic with
a few electronic influences, and all instrumentals. The full project will
be ~10 songs I think.
I wanted to share the first song of this project, if people are interested.
I would be honored if you took a listen to this and said what you think! =)
It's called *Who Stole My Stuff *and is available here:
..and for direct download (mp3) on:
I also want to throw a thanks to Brian Beck (designbybeck) for helping me
out with the artwork!
Thanks a ton for listening/checking this out, if you want to!
I noticed since upgrading to Ubuntu 12.04 that the default Jack server is
jackdmp (v.1.9.8). Please correct me if I am wrong but my understanding this
is the smp-enabled version 2 that is being developed in parallel with 1.x
series of regular jack.
Either way, one of my concerns is that while in the old jack when one
accidentally pulled the soundcard jack was trying to talk to (e.g. a USB
soundcard), the jack would gracefully stop. The new version (and this could
be Ubuntu quirk) instead of stopping is pegged in some kind of a spinlock
that often times locks up the machine (this may be in part since I am
running a lowlatency kernel with audio group given priority) and at times
keeps it operational while hogging the cpu and making the computer barely
responsive until jackd is killed. Apps connected to jack that I tested so
far are also stuck in a loop waiting for a response from jack (although this
could be the app's shortcoming)--jack never broadcasts a signal that it has
lost the soundcard (AFAICT). FWIW I am running jackdmp through qjackctl...
Any thoughts on this matter would be most appreciated.
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-5034 (fax)