Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7444 discussions

by Fons Adriaensen

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 !

16 years, 1 month

Re: [LAD] Realtime and helper threads

by Olivier Guilyardi

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

16 years, 1 month

mic for embedded board

by Patrick Shirkey

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.

16 years, 1 month

microbots for speakers

by Patrick Shirkey

Hmm, Building on the Intel announcement what's the plausibility of using their little transformer robots for building a speaker that can adjust it's shape for the location? -- Patrick Shirkey Boost Hardware Ltd

16 years, 1 month

Re: [LAD] Wireless Electricity vs audio quality

by Patrick Shirkey

Dan Mills wrote: > On Tue, 2008-08-26 at 13:07 +0700, Patrick Shirkey wrote: > > >> They demo'd a 60w light bulb which they said could get 80% efficiency >> upto 3 feet. They are expecting to increase the distance as the RnD >> progresses. You can expect the transfer efficiency and power rating to >> increase with time too. >> > > They demoed a 60W lightbulb in a laboratory environment, there are lots > of things you can do under those conditions that just plain don't fly in > the real world. > > In a sufficiently well screened room with RF reflective surfaces, many > things are possible. > > > I don't see how there was any room for the reflective surfaces in the hall to have an impact on the amount of energy received by the bulb. There was only three feet separating the transmit/recieve points. >> The guy at MIT who designed the circuit has been on record saying it >> will not interfere because the coupling is done at a very specific >> frequency. >> > > That don't help when there are non linear junctions in the area.... > > I call him at best semi competent at either analogue design or design > for emc. Further the occupational limits for non ionising radiation > would (at least in Europe) surely kill this thing. Everyone has cellphones even though the health hazards are still largely unknown. Cigarettes are still legally available too. I don't see why they will stop this technology from coming to market if it has the support of the industry behind it. This particular circuit was first made public about 18 months ago and now that Intel are actively pursuing it I don't think it will be long before Sony, Samsung, Toshiba, Phillips, Apple et al get behind it too. After all Apple get a lot of their new technology from these guys and are using Intel in all their latest PC/notebook lines. > I could also see > serious issues with induction heating of any highly conductive materials > bought into the field, it don't need to be resonant for eddy currents to > heat it. > > I'm agree that this is a serious concern that needs to be addressed but from what I have read they are pretty specific about it not being a problem. This may be along the same lines as the Large Hydron collider creating a black hole to consume the solar system. >>> It >>> will never work well over any distance as the inverse square law applies >>> once you are out of the near field of the aerial (A tuned loop from what >>> I can see - also very old technology), this distance depends on both >>> wavelength and loop dimensions, so making the loop smaller will not >>> improve things). >>> >> >> I believe Tesla would have had a word to say about the above statement... >> > > Well, if you want to play appeal to irrelevant authorities, then Maxwell > would I think agree with my position..... > > Sure and Edison would probably too. > The thing is a cool demo of an air core resonant transformer with a > somewhat high leakage inductance, (and I suspect an automatic matching > and tuning network) but IMHO that is all it is. > > That demo had the look of the canonical 'trade show demo' to me (don't > look behind the curtain). I don't really see much to get excited about > here and there does not to me seem to be anything really new. > > I certainly agree that they had most likely adjusted the environmental conditions to there favor for the demo but from where I stand if/when this tech becomes available for the industry we will definitely be incorporating it into our products. -- Patrick Shirkey Boost Hardware Ltd.

16 years, 1 month

Re: [LAD] OT: alternative fuel for cars [was: Re: Car engine sound emulation for future electic cars. ideas ?]

by Sampo Savolainen

Quoting Patrick Shirkey <pshirkey(a)boosthardware.com>: > Ouch. The blog is just keeping track of recent developments that have > been made that use water as a source of fuel. > > You're right that hydrogen is the actual power source but as hydrogen is > very nicely and efficiently compressed into water it make sense to call > water a fuel. > > If you look through the archives you will see that there are people > running motors with water. Straight out of a bottle and run through this > new circuit that you label childish with enough power to charge a piston > and spin a rotor. What bothered me about these experiments that there was absolutely no description of what they were doing. You've been able to run cars on hydrogen for decades: http://www.youtube.com/watch?v=TjfONpsFvyM "Enough power to charge a piston and spin a rotor"? Where is that power coming from exactly? If you use water as the fuel, you need an alternative energy source to extract the oxygen and hydrogen. By the laws of thermophysics, you will need _more_ energy to do the extraction than what you will get from burning the hydrogen (as burning hydrogen is the exact opposite reaction). If they would actually be using water as a fuel for an internal combustion engine - they would have invented a perpetual motion device as their exhaust would be the same stuff as their fuel. And we all know that's not possible, right? What they are doing is electric motor conversion using hydrogen as a medium to use old style engines. I guess that has it's uses. That seems to be what the company Jack Nicholson was promoting was trying to do. > The people doing the research and experimentation are doing it open > source style with limited funding and resources usually in the garage at > home. It may look unprofessional at first glance but if you look deeper > you will see there is some very professional work being achieved. Don't get me wrong. I want nothing more than get rid of our dependency on gasoline and other fossil fuels and have non polluting options. I'd like more details than videos of bubbling canisters and "exposions". Open Source means, open source, I just see videos and no explanation to what they are doing and _how_. Without explanations the videos look like playing around with dangerous things (electricity, hydrogen) for no good reason. The MIT stuff is way cool though. That looks like it could (and should) change the way we power our lives. But that's using solar energy as the energy store, using water as a battery and hydrogen as a fuel. I'll try to stop now. Sampo "OT" Savolainen

16 years, 1 month

Patching linux 2.6.26.3

by Julien Claassen

Hi all! I'm trying to patch the linux kernel version 2.6.26.3 with the rt-patch. But there's only a patch for 2.6.26. It's not working very well. Because some changes were already taken into the kernel. Which command should I use to do the patch properly. Or should I stop patching all together? Or is there another experimental place to get newer rt-patches. Thanks and kindest regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

16 years, 1 month

Re: [LAD] Patching linux 2.6.26.3

by Jonathan Woithe

Hi > Am Freitag, 22. August 2008 schrieb Robin Gareus: > > Rui Nuno Capela wrote: > > > however, didn't had the time to check whether NOHZ is at stake. i'm > > > certainly going back to 2.6.25.x-rt where things are still sane and > > > pleasant for a while. > > I'll forward this email to LAT. MIDI with 2.6.26 MIDI has not been > > mentioned there. > > USB-sticks don't work here either on 2.6.26... I will go back to <2.6.26 as > soon as time permits. I've been running a tickless 2.6.26 (NOT 2.6.26.3, and not RT) and USB sticks have been fine for me. > What about firewire? has anyone been seeing issues with audio devices or > hard drives? My ffado installation seems to be operating fine under tickless 2.6.26 (again though, 2.6.26.3 and/or RT patches not yet tested). Regards jonathan

16 years, 1 month

Realtime and helper threads

by Olivier Guilyardi

Hi everyone, 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. But the point is that I do not need to do this heavy computation in realtime. The audio samples content is known in advance, it isn't as operating on live audio input. To my understanding, in the realtime thread one is located in some sort of abstract instant, between (input) now and (output) now, and therefore one has very little time. If some computation can be moved out of the RT thread, it ought to be. 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. 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. Is my idea of a helper thread correct? Any clue to set things up properly? Cheers, -- Olivier Guilyardi / Samalyse

16 years, 1 month

LV2 in Ardour 3?

by Darren Landrum

I seem to recall some discussion involving the implementation of LV2 as a part of Ardour 3, along with the MIDI functionality. I was just hoping to confirm whether this is true or not. If it is, what LV2 extensions are going to be supported? I'm really hoping for MIDI, GUIs, and probably the port grouping as well. Thanks for the help! Regards, Darren Landrum

16 years, 1 month

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev