Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

Re: [linux-audio-dev] Utility for recording audio track with midiclock

by Gerrit Niestijl

Hi, Thanks all of you for your comments. I have concluded i should give my plan a try. I'll probably be back here with questions soon. -- gerrit

21 years, 4 months

[linux-audio-dev] hdspmixer issues

by ico＠fuse.net

Hi all! I've been messing with hdsp (again :-) and found out that my hdspmixer has very oddly behaving sound meters. While the input (2nd row) appears to be more or less ok (the yellow peak things kind of fly all over the place and often drop off below green lines or even completely dissapear), the analog outputs as well as combined monitoring output (front 1/4" phono jack on the multiface) only occassionally spike with a line input (usually only one channel). I am wondering why this is so since the audio is definitely working ok, but the monitoring of the outputs simply isn't working (at least not visually). I am using Mdk10.0 community with lots of updates. Alsa 1.0.4rc2 as well as 1.0.5 (libs are from 1.0.4rc2 at this point). Could this be the version of fltk I am using or something more serious? I am using 2.6.5 and 2.6.7 kernels. Any help is greatly appreciated! Best wishes, Ico

21 years, 4 months

[linux-audio-dev] Dynamic resampling

by Olivier Guilyardi

Hi everyone, How should I perform resampling at runtime ? Like : I load samples with different bitrates, then JACK calls my process() callback function using its own bitrate... If the JACK bitrate and the sample one match, there's nothing to do, but if they differ, there's a need for resampling. Do you have an example algorithm, or some pointers, like some app that does this in a nice manner ? Thanks. -- Olivier

21 years, 4 months

Re: [linux-audio-dev] Utility for recording audio track with midiclock

by Gerrit Niestijl

"Tim Goetze" <tim(a)quitte.de> writes: > fwiw, i'm achieving quite satisfying results driving MIDI out from a > 1024 Hz RTC thread, with external hardware locking steadily onto the > output MIDI clock stream, even at tempi up to 240 bpm. > > MIDI out jitter is about the audio block size at max. DSP load (~1.3 > ms) during audio processing cycles, a fraction of a millisecond for > the difference between 1024 Hz and the wanted MIDI clock frequency > otherwise; however this seems to be no problem for the hardware > attached (a fairly recent synthesizer and infrequently an aging cheap > drum machine). > > at lower RTC frequencies, the jitter effect on the MIDI h/w becomes > noticeable (erratic rubato) but it still locks on. > > thus, i must disagree with your 'no way'. Could you point me to some code examples on how you do this? I am an absolute beginner in this. -- gerrit

21 years, 4 months

Re: [linux-audio-dev] Utility for recording audio track with midiclock

by Gerrit Niestijl

> getting a general purpose computer to output MIDI Clock (and/or MIDI > Time Code, just so nobody confuses the two of them) is a very hard > problem. There are 24 MIDI Clock messages per quarter note. This means > that for a piece in 4/4 at 120bpm, you need to output 1 MIDI byte > every 20ms. Not so bad - its a nice even multiplier of the system > interrupt frequency. However, just change the tempo or the time > signature, and all of a sudden you have situations where the MIDI > Clock byte needs to be output every 18ms or every 32ms or ever 9.7ms > or every 56.5ms. Yes, our music involves many (subtle) tempo changes, accelerando's etc. Accuracy would be very important. > until the high resolution clock timers patch is solid enough to be > used by any system, there is no way to schedule MIDI output with this > kind of resolution, and if you can't schedule it, then the receiver of > your MIDI clock signal will see a lot of jitter and may refuse to lock > to it. Even if it locks, its not clear what it will do with the jitter. So it will not work then. That is a pity! >>signal in a audio file, for example with ecasound. I know, this is >>ugly! For playback i would have the program monitor the jack input port and >>output a midi clock message when a sample value of 1 passes by. > > JACK does block structured audio. This won't work. If the "1" is in > the model of a JACK process cycle, when does it actually get delivered > to the MIDI output port? In my naieve view this would simply be done in the process cycle, but you suggest it is not possible? > We'd love to provide this kind of functionality in Ardour, BTW, so if > you're serious about doing the research and work needed to check on > the HRT patch etc etc etc, we'd love to see it done in a way that we > could use too. I would like to contribute to the Ardour project. But i am neither a skilled or an experienced programmer, so i doubt if i am capable to do this. But if there is anything i can do i will do it. Is there any particular documentation i should look at? -- Gerrit

21 years, 4 months

[linux-audio-dev] Linux Audio Blog (continued)

by Jan Weil

Greetings Linux Audio world, the Linux Audio Blog has its own subdomain now. Please find it at http://linuxaudioblog.jawebada.de The RSS feed is available at http://linuxaudioblog.jawebada.de/index.rss While the old links are still valid I'm planning to restructure the rest of my site somewhen in the future. Please update your bookmarks and your feed aggregator's configuration. Contributors are welcome! You can easily contribute to the Linux Audio Blog via an email gateway now (i. e. you *do not* need yet another account). If you are interested please read http://linuxaudioblog.jawebada.de/about/how_to_contribute_to_the_linux_audi… and http://www.jawebada.de/index.cgi/blog/software/autoformat.html Send me an email and I will add you to the list of known posters. Happy coding Jan -- Jan Weil The Linux Audio Blog: http://linuxaudioblog.jawebada.de

21 years, 4 months

[linux-audio-dev] writing gig files (was: giga files and large soundfonts)

by Christian Schoenebeck

Es geschah am Mittwoch, 30. Juni 2004 15:59 als James Stone schrieb: > I was wondering if anyone has any knowledge about generating giga or akai > compatible files? You know we discussed that several times on the LinuxSampler list. At the moment libgig is only capable to read, not to write gigs. Extending libgig with write support would probably take me a week, so it's not that much. But I would only do so if there are people who are definitely willing to develop an instrument editor for the Giga format or extend an existing one. The Giga format is more powerful than the Akai format, so I would definitely prefer that instead of Akai, but the Giga format has some drawbacks: * most important it's based on RIFF, thus it has (officially) a file size limit of 4GB * it's proprietary * it has many relicts in the format which are simply unused nowadays, means there are dirty redundancies * it's binary only, so you can't easily adjust articulation informations with a simple ASCII editor * the unknown fields in the format = relicts (which aren't necessary to know about when you just read the gig) might cause that the original Gigasampler to not accept the patch file anymore after editing / creating it or at least could cost us some time til it actually accepts it. So like with any proprietary format, at the moment I simply can't guarantee that it will also work right away with the original Gigasampler (I'm quite optimistic though) That's why we came to the decision that it might be better to define our own sampler patch file format (maybe XML based) before we implement write support e.g. for the Giga format. What are your opinions? CU Christian

21 years, 4 months

[linux-audio-dev] ardour 0.9beta17.1 released

by Paul Davis

"Less SNAFU's, Less bytes, More Features" This release is more or less identical to yesterdays 0.9beta17, but its only about 3MB instead of 35MB+, and looping while running in sync with JACK is sort-of working. Packagers please take note. Next release expected in less than 8 days but more than 5, and it will hopefully contain the last of the major bug fixes and redesigns before 0.9 is released. --p

21 years, 4 months

[linux-audio-dev] ardour 0.9beta17 botch up

by Paul Davis

something went wrong with "make dist" and the file that was uploaded was abnormally large. it will be corrected around lunchtime (EST) today. sorry for the confusion.

21 years, 4 months

[linux-audio-dev] Ardour 0.9beta17 is 38 Megs????

by J_Zar

Sorry for the wrong (maybe) post... Trying the Ardour download of beta 17 I noticed 38.6 Mb of source code while nightly tarball is 1.7 Megs... Some package error maybe or all is ok??? I don't think autoconf/automake script generation will require 36 Mb.... Cheers, -- J_Zar Gianluca Romanin ---------------- see you at OpenJay.Org

21 years, 4 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