Re: [linux-audio-dev] API for playing wav file samples
04/01/03 12:30, Vandana wrote: > Hi, > I am building a sound editor and need an API for playing 'wav' > file samples. I tried the SOX API but the quality is very bad. Is there > some other API, I can try. Kindly advice. I'm not sure what it is that you want to do. Do you want to play wav files from the commandline or do you want to load them into memory and then play them from there? If the quality of SOX is bad then you are probably not using it properly. Otherwise you can look at libaudiofile or libsndfile, both of these support WAV file loading. Pascal.
Re: [linux-audio-dev] API for playing wav file samples
Vandana wrote: Hi, I am building a sound editor and need an API for playing 'wav' file samples. I tried the SOX API but the quality is very bad. Is there some other API, I can try. Kindly advice. . what language? And did you want it to actually play or just load/save wav files?
Re: [linux-audio-dev] API for playing wav file samples
On Sat, 4 Jan 2003 12:30:24 +0530 (IST) Vandana <[EMAIL PROTECTED]> wrote: > > Hi, > I am building a sound editor and need an API for playing 'wav' > file samples. I tried the SOX API but the quality is very bad. Is there > some other API, I can try. There are a number of APIs. For reading audio files (WAV and others), the most commonly used one around here is libsndfile: http://www.zip.com.au/~erikd/libsndfile/ as well as audiofile and one or two others. For playing files there is OSS (easy but will be dropped for the 2.6 Linux kernel), ALSA (the future of audio on Linux), PortAudio (one API which is portable across many platforms), Jack (client/server architecture for allowing apps to communicate with one another) and probably others. Search for them on http://www.google.com/linux/ . The libsndfile source code includes an example sound file player which uses OSS for Linux, but also works on Solaris, Win32 and MacOSX. Erik -- +---+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ I hack, therefore I am.
[linux-audio-dev] API for playing wav file samples
Hi, I am building a sound editor and need an API for playing 'wav' file samples. I tried the SOX API but the quality is very bad. Is there some other API, I can try. Kindly advice.
Re: [linux-audio-dev] rave + rant (long)
04/01/03 13:08, Erik de Castro Lopo wrote: > The Rabbit (libsamplerate) > == > I am currently working on some major, rather gnarly, refactoring of > the internals which should result in about a 10-30% improvement > in throughput for the Sinc based converters. > > I am also toying with the idea of adding a callback based method of > accessing the library's functionality. > > Mailing lists for the Rabbit here: > > http://www.mega-nerd.com/SRC/lists.html Wonderful, this was just the kind of thing I was looking for. Will check it out, thanks! Pascal.
Re: [linux-audio-dev] rave + rant (long)
On Fri, 3 Jan 2003 17:34:22 -0500 Paul Davis <[EMAIL PROTECTED]> wrote: > but ... but ... i am just glowing with the way libraries like > libsamplerate and libsndfile provide the same simple "just plug it > together" functionality that the unix shell and all our pipe-connected > utilities do. this time, its not to being offered (directly) to > command line users, but to people writing GUI-based software and thus > ultimately to their users. > thanks to erik, thanks to RMS for the GPL and thanks to everybody on > this list and elsewhere who is making this revolution possible. Paul, thanks so much for the recognition :-). Its kinda funny. Back in 1995 when I started using Linux I decided I wanted to give back to the community and since audio was my passion, that was an obvious area for me to work in. My first choice for an application to work on was a sound file editor but I quickly realised what a lot of work that was especially since I had a rather demanding full time job which at times left me with zero free time for up to 6-8 weeks at a time. I was also attempting to get a life :-). When I looked around at the sound file editors available back then I saw that they were all doing their own WAV file I/O, and few of them were doing it was well as some code I had hanging around since my windows 3.1 days in the early 1990s. It was a pretty obvious step to tidy that up, extend it, release it and then encourage people to use it. That work has now been paying off for some time. Over the years I have learnt one hell of a lot about programming, software design, software testing, portablity, project management and the GNU tool chain. I feel very strongly that the use of libraries makes the Free Software and Open Source movements more powerful. Some of the real advantages of libraries are: 1) They encourage code reuse (IMO far better than C++ does) while simultaneously discouraging the propagation of multiple versions of the same code (IMO one of C++'s downfalls : compare a C++ class file which gets copied from source tree to source tree with a library which is maintained separately and gets dynamically linked to multiple applications). 2) They force the partitioning of a whole task (ie writing a sound file editor) into a separate tasks (editor without file I/O and separate file I/O). 3) They force the use of clean, simple interfaces thereby reducing cross dependancies of large chunks of code. 4) Libraries are far more testable than programs with GUIs (have a look at the test suites in libsndfile and the Rabbit) which means the applications can rely on well designed libraries to be reasonably bug free. 5) When multiple applications use the same library it helps track down bugs in the library resulting in a more reliable library (when i started libsndfile, I found a number of windows 3.1 applications which had their own file I/O and wrote broken WAV files). Anyway, thats my rant to add to Paul's. I encourage anyone who is undertaking a new project to see if some of the code can be split off and made into a separate library for everyone to use. I also encourage them to treat it as a separate project and to give it a test suite. This is a little more work in the short term but has huge paybacks later. While I'm at it I should also mention my plans for libsndfile and the Rabbit. Listed in no particular order and no guarantees of when this will be done :-). libsndfile == - Add reading/writing of test strings to file formats that support it. - Add reading/writing of loop points and markers to file formats ... - Add reading/writing broadcast wave stuff to WAV files. - Add ability to optionally add dither on read and write (ie when the source->desination results in a reduction in bit width). - Support for more formats (OGG Vorbis, FLAC, WavPack, PVF etc) In addition, there are now a couple of libsndfile mailing lists which you can sign on for here: http://www.zip.com.au/~erikd/libsndfile/lists.html The Rabbit (libsamplerate) == I am currently working on some major, rather gnarly, refactoring of the internals which should result in about a 10-30% improvement in throughput for the Sinc based converters. I am also toying with the idea of adding a callback based method of accessing the library's functionality. Mailing lists for the Rabbit here: http://www.mega-nerd.com/SRC/lists.html In other news, I am about to take on a small Linux audio based contract (under NDA, so no more details available yet) and hope to find more Linux programing contracts in the future. Cheers, Erik -- +---+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "640K ought to be enough for anybody." -- Bill Gates, 1981
Re: [Jackit-devel] Re: [linux-audio-dev] 2.4.20 + lowlat +preempt +alsa + jack = dead computer
> >I browsed the Kernel Source and there is only one mark_inode_dirty in > >pipe_write (in fs/pipe.c). So we know where it is hanging... > > > >And in __mark_inode_dirty (in fs/inode.c) there is one > > spin_lock(&inode_lock) > >call, and I guess that is where the whole thing is hanging. So something > >is holding that lock... how do I find out who is doing that? Apparently > >the handling of inode_lock is confined to inode.c. I'll keep reading. > > > >Maybe the pipe in question is one of the pipes that jack uses for ipc? > > seems *damn* likely ... sorry to just be chiming in with a useless comment! Do you think the problem might be jack? Some race condition that only happens (or is much more likely to happen) in 2.4.20? It does sound more like a kernel bug, but I have not seen a hung machine without having jack and clients running... -- Fernando
Re: [linux-audio-dev] rave + rant
On Fri, Jan 03, 2003 at 05:34:22PM -0500, Paul Davis wrote: (cut) >thanks to erik, thanks to RMS for the GPL and thanks to everybody on >this list and elsewhere who is making this revolution possible. >--p I'm glowing too :) Don't have the time right now to use all the great apps, but just reading about the coding efforts here and listening to people on LAU, watching the announcements fly by on LAA, seeing new quicktoots, people helping eachother, make me feel ok and know that when I have the time all this stuff will still be around for me to play with. By the way, one of my new year's resolutions was a more active (monetary) support of LAD and other projects of which I actively use the code. I think supporting linuxaudiosystems would be a good start ? What steps can I take ? Its not a huge amount of money, yet I think it can be appreciated :) regards, v
Re: [Jackit-devel] Re: [linux-audio-dev] 2.4.20 + lowlat +preempt + alsa + jack = dead computer
>I browsed the Kernel Source and there is only one mark_inode_dirty in >pipe_write (in fs/pipe.c). So we know where it is hanging... > >And in __mark_inode_dirty (in fs/inode.c) there is one > spin_lock(&inode_lock) >call, and I guess that is where the whole thing is hanging. So something >is holding that lock... how do I find out who is doing that? Apparently >the handling of inode_lock is confined to inode.c. I'll keep reading. > >Maybe the pipe in question is one of the pipes that jack uses for ipc? seems *damn* likely ... sorry to just be chiming in with a useless comment!
Re: [Jackit-devel] Re: [linux-audio-dev] 2.4.20 + lowlat +preempt +alsa + jack = dead computer
[brief description of problem: jack + several other jack clients + disk activity - a tar process, for example - hangs the machine] > This is what I'm currently testing: > > 2.4.20 + capabilities + preempt + lowlat + > [from Con Koliva's page] > Read latency2 disk hack (Andrew Morton) + ACPI + variable HZ (1000) + > [from an older jl patch] > drm low latency + > [from ext3 page] > ext3 patches for 2.4.20 > > I built the icebox kernel debugger to try to get some info on where the > program is hanging and this is what I get in terms of what's happening > (four instances of breaking into the debugger with the Sysrq-d key), > this is the list of tasks: > > 4) [other 3 erased for brevity] > schedule +1ab > sleep_on +45 > bread +20 > __mark_inode_dirty +d9 > pipe_write +1b9 > poll_freewait +44 > sys_write +9f > system_call +33 > > So the system seems to be stuck in __mark_inode_dirty I browsed the Kernel Source and there is only one mark_inode_dirty in pipe_write (in fs/pipe.c). So we know where it is hanging... And in __mark_inode_dirty (in fs/inode.c) there is one spin_lock(&inode_lock) call, and I guess that is where the whole thing is hanging. So something is holding that lock... how do I find out who is doing that? Apparently the handling of inode_lock is confined to inode.c. I'll keep reading. Maybe the pipe in question is one of the pipes that jack uses for ipc? -- Fernando
RE: [linux-audio-dev] rave + rant
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Davis > Sent: Friday, January 03, 2003 2:34 PM > To: [EMAIL PROTECTED] > Subject: [linux-audio-dev] rave + rant > > > it really makes me feel good to be able to turn around and explain to > my disbelieving kids "yes, somebody wrote this really useful software > and they just made it available so that other people could use it. > that made it easy for me to make my software (with which i do the > same) be so much more useful for many people". > > thanks to erik, thanks to RMS for the GPL and thanks to everybody on > this list and elsewhere who is making this revolution possible. > > --p > Sounds like the conversation I was just having with my 10 year old boy who asked 'Dad, where did you get all this software?' 'Free', I said 'off the Internet'. 'Really?' 'Yep, just make sure you help by giving something back'. 'Cool!' Thanks to you Paul from someone further down the pipe!
Re: [Jackit-devel] Re: [linux-audio-dev] Re: [Jackit-devel]2.4.20Â + lowlat +preempt + alsa + jack = dead computer
> > I don't have the time now to analyze the results but it would seem the > > problem is freqtweak in combination with jackd. When the system freezes > > after starting stuff from a text console, sysrq-p prints > > information about the current registers and the printout of repeated > > dumps only shows the jackd and freqtweak processes over and over again. > > Good news (apparently - most probably the machine I'm testing on will > freeze while I'm typing this message :-) It eventually did after I sent the message :-( > The problem with 2.4.20 appears to have been ext3. I finally got a trace > of the deadlocked processes through the sysrq key (after retyping lots > of boring numbers from the screen) and ksymoops is pointing to something > stuck in ext3. With that clue I went to the ext3 site: > > http://www.zip.com.au/~akpm/linux/ext3/ Well, the machine keeps locking even with those patches. A sure way for me to kill it is to run jack, ardour, freqtweak, qjackconnect and a process doing "tar cvf usr.tar /usr" (in the home partition). Sometimes I cannot even start all the stuff and I don't get to the tar process, sometimes it takes a while to die. Adding some heavy disk activity to the mix seems to help kill it faster. But I've seen it die with just jack and ardour running. This is what I'm currently testing: 2.4.20 + capabilities + preempt + lowlat + [from Con Koliva's page] Read latency2 disk hack (Andrew Morton) + ACPI + variable HZ (1000) + [from an older jl patch] drm low latency + [from ext3 page] ext3 patches for 2.4.20 Same results on a quick test with 2.4.21-pre2. I built the icebox kernel debugger to try to get some info on where the program is hanging and this is what I get in terms of what's happening (four instances of breaking into the debugger with the Sysrq-d key), this is the list of tasks: 1) __switch_to +3e schedule +269 sleep_on +45 __mark_inode_dirty +d9 pipe_write +1b9 sys_write +9f system_call +33 2) sleep_on +6f bread +20 __mark_inode_dirty +d9 pipe_write +1b9 poll_freewait +44 sys_write +9f system_call +33 3) __wake_up +55 bread +20 __mark_inode_dirty +d9 pipe_write +1b9 poll_freewait +44 sys_write +9f system_call +33 4) schedule +1ab sleep_on +45 bread +20 __mark_inode_dirty +d9 pipe_write +1b9 poll_freewait +44 sys_write +9f system_call +33 So the system seems to be stuck in __mark_inode_dirty, whatever that is. Each time I break into the debugger I see one of the jack related processes as the current process. No other processes, so I assume the SCHED_FIFO ring is still running but everything else is being blocked by the mark_inode_dirty call. Any interested kernel hackers out there to help with this? Awaiting instructions... :-) -- Fernando
[linux-audio-dev] rave + rant
i just want to stop for a moment and reflect on the power of the open source software model. for a long time, a rather glaring defect in ardour was the inability to record at a higher frame rate (say, 48kHz or 96kHz) and then easily produce an audio file of the piece at 44.1kHz, the standard for redbook cd audio. i avoided trying to add the code because i knew that resampling was complex and had some significant depth to it - i was busy enough with other things. then erik comes along with his libsamplerate library, and it took me less than 15 minutes to add the capability to the backend of ardour (plus another 45 minutes of work on the GUI to control it). now, The Unix Way calls for the use of tools like sox to do this work: small, independent applications that do one thing and do it well. Ok, that's not exactly a good description of sox, but you get the point. There is nothing wrong with this model for some purposes, especially for people who want to play around with many different possibilities. but when rob pike wrote "the unix programming environment", he was clear (at least to me) that the main strength of The Unix Way was in providing a really productive environment for *prototyping*. it turns out that its a really nice environment for getting many kinds of real work done too, especially for many experimental music folks, and i wouldn't want to see the end of the toolset that sox is just one aspect of. but ... but ... i am just glowing with the way libraries like libsamplerate and libsndfile provide the same simple "just plug it together" functionality that the unix shell and all our pipe-connected utilities do. this time, its not to being offered (directly) to command line users, but to people writing GUI-based software and thus ultimately to their users. it really makes me feel good to be able to turn around and explain to my disbelieving kids "yes, somebody wrote this really useful software and they just made it available so that other people could use it. that made it easy for me to make my software (with which i do the same) be so much more useful for many people". thanks to erik, thanks to RMS for the GPL and thanks to everybody on this list and elsewhere who is making this revolution possible. --p
