Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7520 discussions

by Richard Smith

The following post came across the the Open graphics list from one of the founders of the project looking for other things to do with the technology they have developed. I thought I'd post it here. Anyone interested should contact Tim. For anyone who dosen't know what OGD1 is see: http://kerneltrap.org/node/6262 I would think that with a little guidence from this list and tight integration with ardour and jack that a _really_ kicking pro audio setup could be produced. ============= From: Timothy Miller <theosib(a)gmail.com> To: ogml <open-graphics(a)duskglow.com> Since we're having a bit of a lull in the discussions on OGML, I thought I might start off a discussion about some ideas I've had that would benefit the Linux community as well as give OGP and Traversal a boost financially. The Open Graphics Project has gotten everyone involved a lot of attention. While it's still possible to get graphics cards supported by open source drivers, that supply is dwinding. At the rate things are going, we'll soon have no choices left. Politically and socially, the OGP is a great idea. Economically, however, it's entirely a different story. Because of the development and costs involved, low-end graphics is actually not such a great place to start. The attention we get because we want to do graphics is a major driving force, but there are much better ways to get our stream of funds started. One such idea that's been brought up before is ultra high end audio. The low-end is solved; it's called AC97 and is found in every PC chipset you can buy today. But imagine taking what would normally cost tens to hundreds of thousands of dollars in audio recording and production equipment and applying the open source model to it. Designing and producing a low-end commodity product is hard. But designing a niche audio product that sold competitively for thousands of dollars is relatively easy to pull off. To begin with, we now become much less cost-sensitive for parts, so the end product can be FPGA-based. That makes OGD1 an ideal development platform for a new audio device; in fact, it's major overkill. Once the new design is finished, we'd mass-produce a new board using a smaller FPGA and include all of the audio I/O hardware directly on-board. I know basically nothing about audio technology. But given what little I do know, here are some things that I think would be relatively easy to do with OGD1 and, what shall we call it, OAC1: - 60+ audio channels (pick your combination of in and out) - (A specialized card could handle lots more channels) - 24-bit precision per channel - Sample rates in the hundreds of kilohertz - Thousands of audio samples and MIDI instruments - Sample-based and algorithmically-generated sound-effects - Fourier analysis, band filters, mixing, and other sorts of math stuff that if I could name it, you'd be impressed - Noise-free signals (because we have experience with graphics) - Accelerated "3D sound" - Accelerated compression/decompression - Lots of other things Given hardware acceleration for most parts of audio processing, plus some excellent piece of open source sound studio software, I don't see why we couldn't produce a combination that is as good as or better than what you find in music recording studios, television stations, and every other place where you might find a need for this. Imagine how much money this could save musicians. The only thing we can't provide is the recording room with the proper accoustics. If a reduced version of the card sold for $1000, we'd have more than a few gamers and multimedia enthusiasts buying it for their 50-speaker surround-sound reality-immersion systems. Were such a project started, I would have to carefully tune my involvement. Since Howard, Andy, and I do not have a background in audio technology, it would probably be best for someone with appropriate experience to lead. But if the community can spec this product and help us design it (we can put into hardware any algorithm you specify), Traversal can produce it. The whole project, from start to finish, would be developed under GPL. This would be quite a major effort, due to the requirement for more than just drivers. Unlike the OGP, which started out of a corporation and has retained some of that flavor, the OAP would have to organize itself and push itself along. In my mind, the first major problem is getting the right people in the community together to develop the specs. So, what do you all think of this idea? Comments? Suggestions? Discussion! :) ================== -- Richard A. Smith

19 years, 8 months

[linux-audio-dev] liblo: restarting the server thread

by Dave Griffiths

Hi all, I'm trying to restart a liblo thread with the same port, but something seems to being kept hold of, as it fails (this may be intentional though). I have a test case here - am I being daft, or should this work: ---8<--- #include <stdio.h> #include <lo/lo.h> void handler(int num, const char *msg, const char *path) { printf("liblo server error %d\n",num); } int main() { printf("once\n"); lo_server_thread thr = lo_server_thread_new("4444",handler); lo_server_thread_start(thr); lo_server_thread_stop(thr); lo_server_thread_free(thr); printf("twice\n"); thr = lo_server_thread_new("4444",handler); } --->8--- I get the output: once twice liblo server error 9904 cheers, dave

19 years, 8 months

[linux-audio-dev] EMU 1212M

by Dmitry Baikov

On 4/6/06, James Courtier-Dutton <James(a)superbug.co.uk> wrote: > Creative have actually donated an X-Fi and an EMU1212M to me. > No datasheets, but at least having the hardware is a start. (Creative > pass me some datasheets for other cards though) > I have currently got as far as horrible noises coming from the EMU1212M. So, does it mean that soon we'll have linux drivers for Emu 1212, 1616 and 1818? Regards, Dmitry.

19 years, 8 months

[linux-audio-dev] fast linear resampling on ARM - suggestions?

by Tobias Scharnberg

Hello List, I'm trying to find a library or code-snippet in order to do audio resampling from 8khz to 44,1khz and from 44,1khz to 8khz. I need to resample the data in realtime - resampling a buffer of data, not a soundfile. The quality doesn't need to be good so I guess the best solution might be linear audio resampling. The device to do the resampling on is an ARM CM-X255 running at 400MHz. I tried out libsamplerate so far but when I tested it with the soundfile conversion test program it needed 3,5 secs to sample from 8kHz to 44,1 khz for a 1,7 secs audiofile - which is too slow for me. Is there something faster that can do the job? Any suggestions are highly welcome Greetings, Tobias

19 years, 8 months

Re: [linux-audio-dev] Re: GPL Audio Hardware

by Sampo Savolainen

Quoting Dave Robillard <drobilla(a)connect.carleton.ca>: > On Tue, 2006-04-04 at 13:22 +1000, Loki Davison wrote: > * At least 1 ADAT Lightpipe in/out I'd vote for at least 4 ADAT inputs so you could connect two 8 channel preamps using 88.2k or 96k to the device. ;) Sampo

19 years, 8 months

[linux-audio-dev] Re: [linux-audio-user] regarding the 2nd Book Of Linux Music & Sound

by Dave Phillips

Greetings: First, thank you to everyone who responded to my original query. I now have a much better idea how I want to do this project. I definitely want to involve members of this group. Some of you have offered to take on particular chapters, and that seems to me the best approach. I believe we can complete the work in record time by spreading the work around. I'll speak with my publisher about this plan. If he approves this approach we'll start work immediately. Some respondents wrote to me off-list and have offered to assist. I'll be in touch with you all after talking with Bill Pollock. If Bill gives us a green light I'll start organizing the distribution of work immediately. I'll communicate directly with you regarding style preferences, format requirements, deadlines, etc. I must emphasize that this project is commercial work, i.e., we'll have editors at the publishing house and there will be demands that certain dates be met. Please, only take on the work if you're sure you can work under those conditions. If the community approach is accepted I'll post a list of topics and areas that need attention. I have a large amount of unedited/incomplete material that I'm willing to offer as starting points. I've been thinking about the royalties issue. I'm far from a final plan, but I think it might be possible to route some (all?) of the royalties to the Linux Audio Consortium. The community can then decide how to use it. I can't leave this issue vague, my publisher will need to know who is in charge of accounts receivable, and I can't simply accept contributions from the community and not reimburse those contributors. How that reimbursement takes place can be left to the individual contributors, or we may decide to simply throw everything in one direction (e.g. linuxaudio.org). Btw, I especially appreciate the community's response re: the 2.4 kernel series. It is laid to rest, there will be coverage only from kernel 2.6 upwards. Thank goodness. No Starch has already accepted my outline for the project. At some point I'll post that outline on the Web for the community to consider. However, please bear in mind that there will be limitations of space and scope. I'm unlikely to be able to cover games, consumer devices, or telephony. Alas, material for a programmer's guide will probably not be accepted. IMO that really requires a separate book now. A developer's guide to ALSA and JACK is certainly timely and needed, but I'm not the one to write that book. Again, if you're interested in writing for this project please contact me off-list. Specify your area of interest and we'll go from there. Best regards, dp

19 years, 8 months

[linux-audio-dev] python: thread cpu usage

by Patrick Stinson

Does anyone know how to get the cpu usage of a specific thread from python? (I don't subscribe to python-list, too much traffic)

19 years, 8 months

[linux-audio-dev] pysndfile, pyrtaudio, pyrtmidi, pysoundtouch

by Patrick Stinson

I just finished writing python bindings for libsndfile if anyone is interested. I only wrapped the functions I needed to read files, but I could reasily finish the wrapper in a couple of hours if anyone is interested. unit tests are included. That makes the following python extensions available on my site. They all seem to work on OS X and linux: pysndfile pyrtaudio pyrtmidi pysoundtouch (not quite functional) Let me know if anyone has problems or comments, this was quite fun to do, and I'd like to make them complete for the sake of the world... -- Patrick Kidd Stinson http://www.patrickkidd.com/ http://pkaudio.sourceforge.net/ http://pksampler.sourceforge.net/

19 years, 8 months

[linux-audio-dev] Pyphat 0.1 and phat 0.4 released.

by Loki Davison

G'day All, The first release of phat python bindings, pyphat and an updated phat are now out. 2 new widgets are added, phatknob and phatpad. Phat pad is a 5-d input pad that is xinput enabled. X, y, pressure, tilt x and tilt y can returned when used with an xinput device such as a graphics tablet. Knobs and fansliders know have a log mode and an resize bug in sliderbuttons is fixed. Both can be download at http://phat.berlios.de/ Cheers, Loki

19 years, 8 months

[linux-audio-dev] libsndfile: sf_seek return value

by Patrick Stinson

has anyone seek sf_seek return zero on success instead of the frame offset from the start of the audio data, as it says in the API docs? The seek appears to work because a call to read behaves correctly at the end of the stream afterwards. Thanks.

19 years, 9 months

Jump to page:

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