Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7536 discussions

[LAD] Mind control hardware/software for Audio

by Patrick Shirkey

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.

17 years, 5 months

Re: [LAD] Mind control hardware/software for Audio

by Nathanael Anderson

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

17 years, 5 months

[LAD] [somewhat OT] semaphores in python

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 !

17 years, 5 months

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

17 years, 5 months

[LAD] 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.

17 years, 5 months

[LAD] 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

17 years, 5 months

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.

17 years, 5 months

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

17 years, 5 months

[LAD] 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

17 years, 5 months

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

17 years, 5 months

Jump to page:

2026

2025

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