Hartmut Noack wrote:
> Cory K. schrieb:
>
> > * Shipping the -generic kernel with this 8.10 release of Ubuntu
> > Studio and let people compile their own -rt kernel.
>
> This could be done in any Distro so there would not be a real
> Ubuntustudio anymore.
I don't agree completely since our focus is not *just* audio, though we
know that's our biggest user segment.
> The major strength of UBuntustudio is its
> near-perfect integration of a audiosystem with a friendly desktop-distro.
> I can run VMWare and NVIDIA-Drivers easily with the UBuntu rt kernel
> would be a major p.i.t.a. do make stuff like that run with a self made
> kernel.
These could also be the very things you lose.
> > * Ship a out-of-sync 2.6.26-rt kernel, hoping for a Stable Update
> > Release in Intrepid with .27 later.
>
> This would be perfectly acceptable for me :-)
>
>
> best regs
> HZN
>
> BTW: what is so extremely important in .27? new hardwaresupport not
> achievable with .26?
Much better suspend/resume support along with many bug-fixes and device
support.
-Cory K.
Hello all. This is going out to a couple of lists so I can get as wide
an opinion as I can. I'll correct any inaccuracies as this discussion
progresses.
Quick intro: I'm Cory K. Lean on Ubuntu Studio. Hi :)
So here's the pickle we're in as I understand it.
The way the kernels are now managed in Ubuntu has changed radically in
this release. Thus causing our kernel guy *much* more work that ever
before. We've had to work very hard to get upstream -rt to support the
.26 kernel but, now mainline Ubuntu has moved to 2.6.27. Which upstream
-rt doesn't *look* to support yet.
So because of these, and other issues that don't matter to the question
I have we're looking at these options:
* Shipping the -generic kernel with this 8.10 release of Ubuntu
Studio and let people compile their own -rt kernel. With a latter
PPA release of -rt for testing as upstream support happens.
* Ship a out-of-sync 2.6.26-rt kernel, hoping for a Stable Update
Release in Intrepid with .27 later.
Of some combination of those.
Thoughts on what to do? What do users want? (please be mature)
-Cory K.
Kryz, your mail-severs seems to be down and when I checked out if you
had a running WWW, I got this message:
"Chwilowo nic tu nie ma" [We are not here yet]
So, back to the list ... This time corrected as per second mail:
On Tue, 2008-08-26 at 11:12 +0100, Krzysztof Foltman wrote:
> Jens M Andreasen wrote:
> > I am doing some preliminary testing of CUDA for audio, Version 2 (final)
> > has been out for a couple of days, and this is also what I am using.
>
> Does it require the proprietary drivers and/or Nvidia kernel module?
>
Yes, and not only that. The proprietary drivers distributed with say
Mandrake, Ubuntu et al won't work either. Uninstall that, change your X
setup to vesa (to stop recursive nvidia installer madness) and then get
your CUDA driver and compiler from:
http://www.nvidia.com/object/cuda_get.html
> What kind of things is the gfx card processor potentially capable of
> doing? Anything like multipoint interpolation for audio resampling
> purposes? Multiple delay lines in parallel? Biquads? Multichannel
> recording to VRAM?
Multichannel recording by itself would be a waste of perfectly good
floating point clock-cycles, but anything that you can map to a wide
vector (64 to 196 elements) is up for grabs. A 196 voice multi timbral
synthesizer perhaps or 64 channel-strips with basic filters and
compressor/noise-gate for remix. The five muladds needed for a single
biquad filter times the number of bands you need to equalize on fits the
optimal programming model quite well.
The linear 2D interpolator is also available and even cached. Perhaps
not the worlds most useful toy for audio-resampling, but could find its
way into some variation of wave-table synthesis. It can be set up to
wrap around at the edges, which I find kind of interesting.
Random access to main (device) memory is - generally speaking - a bitch
and a no-go if you cannot wrap your head around ways to load and use
very wide vectors.
There are some 8096 fp registers to load into though, so all is not
lost. Communication, permutation and exchange of data between vector
elements OTOH is then fairly straight forward and cheap by means of a
smallish shared memory on chip.
The more you can make your algorithm(s) look like infinitely brain-dead
parallel iterations of multiply/add, the better they will make use of
the hardware. The way I see it, the overall feel of your strategy should
be something like "The Marching Hammers" animation (from Pink Floyd: The
Wall.)
> Is it possible to confine all the audio stream transfer between gfx
> and audio cards to kernel layer and only implement control in user
> space? (to potentially reduce xruns, won't help for control latency
> but at least it's some improvement)
>
Yuo you mean something like DMA? Yes I would have thought so but this is
apparently not always the case, Especially not on this very card that I
have here. :-/
The CUDA program running on the device will have priority over X though.
So no blinking lights (nor printfs) before your calculation is done. For
real-time work, I reckon this as a GoodFeature (tm)!
Potentially this can also hang the system if you happen to implement the
infinite loop (so don't do that ...)
> Would it be possible to use a high level language like FAUST to
> generate CUDA code? (by adding CUDA-specific backend)
>
The problem would be to give Faust a good understanding of the memory
model and how to keep individual vector elements away from collectively
falling over each other.
But I must admit that I am not too familiar with what Faust is actually
doing? Would it be of any help to you with a library of common higher
level functionality like FFT and BLAS?
---8<---------------------------------------------
- "CUBLAS is an implementation of BLAS (Basic Linear Algebra
Subprograms) on top of the NVIDIA(r) CUDA(tm) (compute unified
device architecture) driver. It allows access to the computational
resources of NVIDIA GPUs. The library is self-contained at the API
level, that is, no direct interaction with the CUDA driver is
necessary."
------8<................................
But observe that:
... - "Currently, only a subset of the CUBLAS core functions is
implemented."
/j
> Krzysztof
>
Hi,
After the latest Intel announcment that they are indeed working
seriously on wireless electricity uses resonance to transmit hte energy
sources I am wondering if anyone has ideas on whether that would affect
audio quality as resonance is an important part of the ambience of live
sound.
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd
Hi,
One of the other technologies demoed last weekend by Intel was so called
mind control hardware which is effectively a little cap that picks up
electrical signals from the brain and can be used to control
software/hardware depending on the thoughts/actions of the wearer. I
have seen video games where this is used to great affect to for example
light a fire by meditating and the deeper the meditation the
warmer/brighter the fire becomes.
Does anyone know of any development that is going on in Linux Audio
circles that applies this technology?
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd.
I've been thinking about the same thing. Specifically I wanted to try and
use an OCZ NIA for drum input into hydrogen. I've seen a few videos of them
people demoing the unit, but don't personally know anyone that's tried one.
There is no linux support afik either for them. I'd be interested if you
make any progress to hear about it.
Nathanael
Hello all,
Does anyone know of a counting semaphare class/module
in Python ? Given the lock provided by the built-in
thread module it seems impossible to implement this
(it does support multiple waiters which I don't need,
but definitely is not counting). This also means that
whatever is defined in the threading module can't be
what I want.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
O tu, che porte, correndo si ?
E guerra e morte !
Hi Dan,
why don't you answer on the mailing list?
Dan Mills wrote:
> On Fri, 2008-08-22 at 20:26 +0200, Olivier Guilyardi wrote:
>>
>> In Jackbeat I perform sample rate conversion using libsamplerate in the realtime
>> thread. I have recently realized that might be a mistake in regard to
>> performance. The SRC is used on audio samples which sample rate might differ
>> from the external (Jack) one, and also as a simple pitch shifter.
>
>
> <Snip>
>
>> In this regard, I thought about setting a (or several) non-RT helper thread(s)
>> up, where the heavy stuff would happen, and feed the converted content into the
>> RT thread through a ringbuffer. I understand that this approach would require
>> implementing a sync callback for the helper threads to get ready (fill buffers,
>> etc...) whenever the transport position changes.
>
> That is a fairly common approach, one thread per core is good. I have
> code that reads audio, sample rate converts it, time-stretches it if
> appropriate and sticks it in a ring buffer. The realtime thread does not
> pay any attention to the transport at all, it just handles the realtime
> controls (some mixing and routing in my case).
I am unsure what you mean by "core".
> One thing you do want to watch is that the disk IO threads should
> probably run at a realtime priority (just lower then the one for the
> audio thread), otherwise a make -j10 on the kernel can result in
> ringbuffer under run.
Disk IO is another problem to me. I would prefer to focus on computation load
here, that is: helper threads that performs audio conversion/transformation,
etc.... I assume that the thread priority you advise also concerns this though.
> There are a few details to making everything work right when you have
> more playbacks then available cores, and the approach does not work well
> if you need to vary things like timestretch in realtime.
Ah right, thanks, I had forgotten about this. Indeed, the good side of my
current approach (where the SRC is performed in the realtime thread) is that it
gives the user a good experience when varying the pitch: the effect is
immediate. So I'm not operating on live audio input, but I do handle live
"control" input, and in this regard the audio sample content is not exactly
known in advance anymore (since it is transformed according to realtime user
requests).
>> I'm asking this because the SRC computation load currently has an impact on the
>> output quality (ticks, xruns) with many tracks or on slower systems, and I'm
>> thinking about adding real pitch and time shifting using Rubberband in the near
>> future, which is certainly going to be a lot heavier.
>
> If you need to be able to vary the timestrtch in real time with a file
> playing, any ring buffer after the timestretcher will need to be short,
> otherwise it is fairly straightforward.
That worries me a bit. If my ringbuffer is really short, for responsive user
control, and the time stretching performed in a non-RT thread, isn't this going
to make things worse?
What about the following idea:
Say I make a Converter object, which performs time stretching. It doesn't know
anything about threading.
I also have a Reader object, with an internal ringbuffer, it reads raw audio
data, converts it using the Converter, and fills its ringbuffer with the
converted content.
The Reader objects exposes read(double time_ratio, int nframes) to the realtime
thread. When this function gets called, the Reader checks if it has data time
stretched according to this time ratio in its internal ringbuffer. If it does it
simply returns it. Otherwise, it calls the Converter on the fly, discarding the
irrelevant data in the ringbuffer, and causing a sudden small overhead.
Once the time ratio has stopped varying (the user has stopped playing with the
knob), the ringbuffer rapidly gets filled with data at the right time ratio, and
the overhead vanishes.
> Volatile is your friend as is pthread_mutex_trylock (Particularly handy
> if you have a vector of disk readers and a small handful of threads
> servicing them).
Thanks, I knew little about volatile, I've read some more about it, and already
fixed a possible bug in my code. Yes, I recently read about
pthread_mutex_trylock being acceptable in the realtime thread on the jack-devel
mailing list.
Regards,
--
Olivier Guilyardi / Samalyse
Hi,
Does anyone have a suggestion or a part number for a small mic that can
be fitted onto an embedded board that also has good quality input levels?
I have a few options already but someone here might be able to suggest
one that they have worked with and had good results from.
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd.
