Re: [LAD] [LAA] [ann] gjacktransport 0.4.0

[Robin Gareus]

On 10/29/10 20:25, alex stone wrote:
> On Fri, Oct 29, 2010 at 10:22 PM, Niels Mayer  wrote:
>> On Tue, Oct 26, 2010 at 10:05 AM, Robin Gareus  wrote:
>>> http://gjacktransport.sourceforge.net/ is a tool that provides graphical
>>
>> Thanks!! Works great and provides functionality I was looking for just 
>> recently.
>>
>> One small nitpick is that when the transport is rolling, the area
>> displaying the rolling  HH:MM:SS.mmm timecode jiggles around since the
>> font is proportionally spaced. (at least w/ my display and fonts and
>> setup). Monospaced fonts for such rolling values can prevent this
>> minor visual distraction.
>>
>> -- Niels
>> http://nielsmayer.com
>> ___
>> Linux-audio-dev mailing list
>> Linux-audio-dev@lists.linuxaudio.org
>> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>>
> 
> gjackclock -C black -c yellow -S Sans
> 
> Smooth as silk...
> 
> Alex.

I think Nils is refering to gjacktransport not gjackclock.

The former is using the gtk-theme-fonts and there's no dedicated
config-option for gjacktransport's SMPTE font, yet.

You should be able to override it with some fancy GTK-config or by
changing the desktop-theme until I get around to fix it.
Thanks for the report. I did not notice it because it's not an issue
with the gtk-theme here.

I do have a few more updates in the queue: both apps still need a man
page, the website is out-of-date and Paul Davis suggested to make
gjackclock's font scale with window-size...

stay tuned,
robin

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Bug#600751: RFP: libltcsmpte -- linear timecode and framerate convertion library

[Robin Gareus]

Package: wnpp
Severity: wishlist


* Package name: libltcsmpte
  Version : 0.4.2
  Upstream Author : Robin Gareus 
* URL : http://ltcsmpte.sourceforge.net/
* License : LGPL
  Programming Lang: C
  Description : linear timecode and framerate convertion library

Linear (or Longitudinal) Timecode (LTC) is an encoding of SMPTE timecode data 
as a Manchester-Biphase encoded audio signal. The audio signal is commonly 
recorded on a VTR track or other storage media.
libltcsmpte provides functionality to both encode and decode LTC from/to SMPTE
and can perform framerate conversion tasks.



-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101019182711.10011.77187.report...@soyuz.local

Bug#600751: RFP: libltcsmpte -- linear timecode and framerate convertion library

[Robin Gareus]

Package: wnpp
Severity: wishlist


* Package name: libltcsmpte
  Version : 0.4.2
  Upstream Author : Robin Gareus 
* URL : http://ltcsmpte.sourceforge.net/
* License : LGPL
  Programming Lang: C
  Description : linear timecode and framerate convertion library

Linear (or Longitudinal) Timecode (LTC) is an encoding of SMPTE timecode data 
as a Manchester-Biphase encoded audio signal. The audio signal is commonly 
recorded on a VTR track or other storage media.
libltcsmpte provides functionality to both encode and decode LTC from/to SMPTE
and can perform framerate conversion tasks.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [LAD] jackd and usb hub

[Robin Gareus]

On 10/13/10 20:01, Luis Garrido wrote:
> On Wed, Oct 13, 2010 at 2:02 PM, Robin Gareus  wrote:
>> With the USB2 hub I also get
>> ALSA urb.c:856: cannot submit datapipe for urb 0, error -28: not enough
>> bandwidth
>> ALSA midi.c:214: urb status -32
>> messages and jackd won't start.
> 
> Does the hub cause this problem also through a regular USB port (not PCMCIA)?

yes it does.

>> but connecting the UA-25 directly to the PCMCIA/USB2 card works if I
>> also connect some external power supply to the PCMCIA card. Did you try
>> that?
> 
> Believe it or not, that combination hadn't crossed my mind yet: using
> the brand new shiny and otherwise useless hub as a 16 € glorified 5V
> regulator between its power supply and the PCMCIA card. Why the heck
> not, eh? One fewer layer, too.
> 
> Well, there's my workaround, thanks Mr. Gareus! But (it couldn't have
> been that easy, could it?) only works on one of the two USB/PCMCIA
> ports. 

Weird. Well, just use the one that works :-p

> Trying to use the other one gets me this nice message:
> 
> ALSA sound/usb/usbaudio.c:1348: 40:1:1: usb_set_interface failed
> 
> Bleh.
> 
> Anyone interested in a moderately used Edirol UA-25 interface with
> some occasional -74 dB noise at 13.1 kHz, and a penchant for serial
> (bus) killing?

what are you going to do? get a Firewire device?

> Anyway, I think this hub issue is worth looking into. Old USB 1.1 hubs
> don't mess with realtime audio and new USB 2.0 do? 

It looks like (in my case) the hub is actually translating from USB2 to
USB1.1 and thereby causes some overhead.

If I connect both an external HDD and a cheap (usb1.1) mouse to the hub
(which is connected to the USB port of my laptop) the HDD still gets max
throughput (>30MB/s).

> Now that's not
> exactly what I'd call an improvement. What can we expect from USB 3.0?
> 
> Cheers,
> 
> L
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] jackd and usb hub

[Robin Gareus]

On 10/13/10 08:58, Luis Garrido wrote:
>> PS. Did you have luck with your UA-25?
>
> Nothing new, I am waiting to get my hands on different hubs to see if
> there is any difference.

There is. I just got my hands on both a USB2 hub and a PCMCIA [1] card.

With the USB2 hub I also get
ALSA urb.c:856: cannot submit datapipe for urb 0, error -28: not enough
bandwidth
ALSA midi.c:214: urb status -32
messages and jackd won't start.

but connecting the UA-25 directly to the PCMCIA/USB2 card works if I
also connect some external power supply to the PCMCIA card. Did you try
that?

It also still works with an old USB1.1 hub.

HTH,
robin

[1] it's some cheap mycom thingy which shows up as

16:00.0 USB Controller: NEC Corporation USB (rev 41)
16:00.1 USB Controller: NEC Corporation USB (rev 41)
16:00.2 USB Controller: NEC Corporation USB 2.0 (rev 02)

Subsystem: 1033:0035 (ohci_hcd) and
Subsystem: 13e6:1201 (ehci_hcd)
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Some new things to play with

[Robin Gareus]

On 10/11/10 16:35, f...@kokkinizita.net wrote:
> On Mon, Oct 11, 2010 at 03:47:43PM +0200, Robin Gareus wrote:
>   
>> That's 3 steps to much :)
> 
> Are Linux users becoming that lazy ? :-)

LOL. It's the other way 'round: I'm using GNU/Linux because I'm lazy.
Solve things once, make a script and be done with it.

>> With git it's also easy to keep more than one repo: fi. a private with
>> all the small changes and a public where you only push out releases.
> 
> I don't think that my provider (hosteurope) provides a git server.

There's a lot free git hosting services (from github over gitorious to
sourceforge,..).

>> As for the 'sudo make install' - I'm quite reluctant to run that
>> command.
> 
> I can't help to spot some contradition there. You would not trust
> 'sudo make install', even if you can verify very easily what it's
> going to do (just a few lines in the Makefile).

or by running  `make -n install; echo "really continue? "
read -n 1 ; make install`

> But you would trust
> a single-command, almost automatic update ? This can do whatever it
> wants with your system, even if going through a managed package,
> and it's less easy to verify.

Packaging happens with 'fakeroot', but yeah you have a point there.

However my motivation for bringing all this up in the first place was
not about trust but about convenience.
I do trust your code and even trust you with my door-key.
Are you hinting I should be more careful in the future with installing
your software? 8-)

Anyhow, if there's not going to be a public git or svn repo I'll just
extend my download/compile/package/install script. Actually less work
than typing this email..

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Some new things to play with

[Robin Gareus]

On 10/11/10 14:33, f...@kokkinizita.net wrote:
> On Mon, Oct 11, 2010 at 01:02:09PM +0200, Robin Gareus wrote:
> 
>> Are they also available from some repository (svn, git,..)?
> 
> No. Most projects here are in svn and I'm exploring git
> for a few of them. But the repositories are not nor will
> ever be on a public server. There is no team development
> on any of my projects, and I'm not planning any. 

Well, as outlined below I am suggesting git/svn not as means for
concurrent/team development but for providing a canonical
version-independent URL that can be tracked for each of the projects.

A symlink 'zita-rev1-latest.tar.bz2' could provide the former, but one
won't be able to tell if there's any update without actually downloading
it or checking the mtime with HTTP-HEAD.

>> watching http://www.kokkinizita.net/linuxaudio/downloads/index.html
>> and upgrading apps there (which are not [yet] in common distributions)
>> by hand is kind of tiresome, even more so since your Makefiles do not
>> support 'make uninstall'.
> 
> Well... they are *source* packages. All it takes is download,
> unpack, cd, sudo make install. 

That's 3 steps to much :) Besides: The issue with download is that the
next version number is not predictable. One needs to use a web-browser.
If it was a repository-checkout it'd be a one-time setup and just
calling a single 'pull & build' script afterward.

With git it's also easy to keep more than one repo: fi. a private with
all the small changes and a public where you only push out releases.

As for the 'sudo make install' - I'm quite reluctant to run that
command. Usually a 'make' suffices for testing.
..and if I can't wait until a tool makes it into Debian I roll my own
package for the meantime which provides for clean removal later on.

> The 'make remove' is a good idea,
> I will be adding it to new releases.

The commonly used target (autotools) is "make uninstall"
(not "make remove")

> OTOH, the installed size of
> e.g. zita-rev1 (binary and *.png) is less than 100k, so little
> is gained by removing it. 

The motivation is not about recovering disk-space about being able to
keep the system clean.

Some of my earlier test|development machines|chroots quickly became
messed up with different versions in /usr/lib /usr/local/lib and after a
few weeks or month there was no hope but to re-install the thing.
You may know this situation.

The overhead of rolling custom packages is small compared to
re-installing or cleaning up by hand.

>> The nice thing is that your Makefiles are pretty clean. using dh_make,
>> DESTDIR and quilt (change PREFIX to /usr)
> 
> you can define PREFIX on the make command line as well, there's
> no need to modify the Makefile

aaw right.
PREFIX=$HOME/usr make install # does not work but
make PREFIX=$HOME/usr install # does

Thanks for the hint.

>> makes it easy to debianize them for local packaging; however if
>> one could use git-buildpackage it would be even nicer.
> 
> Installer managed packages (taking care of dependencies etc.)
> should be provided by the packagers of your distro, there's
> no way I can do this. I don't even provide them for the distro
> I use myself.
> 

I agree programmers should not be concerned about packaging. I was just
suggesting a few trivial changes that'll make live easier for PPL
packaging (either for distros or for their own benefit).

Anyway congratulations on these effects. I've only tested the reverb  (I
don't [yet] have use for an autotuner) and it's brilliant.
I'm already looking forward to 'rack GUI'. Keep up the good work.

Cheers!
robin

PS.
Do you know or have any mirrors of kokkinizita.net? It'd be a pity if
all the great stuff on there would be lost in some accident.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Some new things to play with

[Robin Gareus]

On 10/10/10 22:10, f...@kokkinizita.net wrote:

> More info at 

Hi Fons,

Are they also available from some repository (svn, git,..)?

watching http://www.kokkinizita.net/linuxaudio/downloads/index.html
and upgrading apps there (which are not [yet] in common distributions)
by hand is kind of tiresome, even more so since your Makefiles do not
support 'make uninstall'.

The nice thing is that your Makefiles are pretty clean. using dh_make,
DESTDIR and quilt (change PREFIX to /usr) makes it easy to debianize
them for local packaging; however if one could use git-buildpackage it
would be even nicer.

2c,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] jackd and usb hub

[Robin Gareus]

On 10/09/10 11:40, Luis Garrido wrote:
> Has someone else here managed to successfully run jack over USB audio
> through an external hub?

Hi Luis,

I'm just trying this and it works. jackd at 48k*1024*3 produces
occasional x-runs which it otherwise does not.

Jackd even starts up with 48k*64*3 and runs a freeverb in->out with no
x-run! 5mins at the time of writing this email.


Laptop-USB -> Hub (old USB1.1) -> UA-25

#lsusb -t:
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
|__ Port 1: Dev 8, If 0, Class=hub, Driver=hub/4p, 12M
|__ Port 3: Dev 9, If 0, Class=vend., Driver=snd-usb-audio, 12M
|__ Port 3: Dev 9, If 1, Class=vend., Driver=snd-usb-audio, 12M
|__ Port 3: Dev 9, If 2, Class=vend., Driver=snd-usb-audio, 12M
...

#uname -a
Linux soyuz 2.6.33.7-rt29 #1 SMP PREEMPT RT Fri Sep 17 04:25:08 CEST
2010 i686 GNU/Linux

#cat /etc/debian_version
squeeze/sid

#jackd --version
jackdmp 1.9.6

on a 3 1/2 year old Thinkpad X60s.

I had a PCMCIA USB2 card but I gave that away to a friend, sorry I can
not test this at the moment.

have a nice weekend,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [oauth] Accessing Twitter using liboauth

[Robin Gareus]

On 09/23/10 03:03, SJM wrote:
> Hi there,
> 
> I was wondering if anyone has had success in accessing Twitter using
> liboauth (the C library). I have been able to authenticate against the
> Twitter Oauth API, but when I want to send a status message I get a
> signing error.
> 
> HTTP-reply: 
> 
> /statuses/update.xml?
> oauth_consumer_key=x&oauth_nonce=WR5oK1s9HxdZhM2ugZ95&oauth_signature_method=HMAC-
> SHA1&oauth_timestamp=1285189327&oauth_token=x&oauth_version=1.0&status=128518924112851893121285189313TEST&oauth_signature=aDRA99d2CY55gjL7kU1X
> %2FaneqtQ%3D
>   Incorrect signature
> 
> 
> I (triple) checked all my keys and secrets and the order of items in
> the request matches that in the signing URL. liboauth all works for
> the authentication, but the Twitter 'service' API just can't seem to
> agree with  me with regards the signature.
> 
> I suspect that it may be related to UTF-8 encoding. Is there something
> I need to set in the HTTP header for this?
> 
> Any help would be most appreciated,

we did figure this out off-list: but for future reference:


On 09/25/10 06:52, Stan Malachowski wrote:
> Yes - a typo. http://api.twitter.com/statuses/update.xml works, but
> http://api.twitter.com/1/statuses/update.xml is in the Twitter docs.
>
> Your lib works fine. If I had done the POST in the first place I
> would have saved a couple of days.
> 
> Stan
> 
& robin

-- 
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oa...@googlegroups.com.
To unsubscribe from this group, send email to 
oauth+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/oauth?hl=en.

Re: [LAD] question about multithreaded externals in Pd

[Robin Gareus]

On 10/02/10 03:13, Ivica Ico Bukvic wrote:
> Many thanks for the clarification Robin, really appreciate it!
> 
> One more thing I realized, isn't the secondary thread effectively blocking 
> the lock on the main thread because the mutex_lock is placed before the cond 
> call or is this the right way to do it? Namely, should secondary thead have 
> the following structure:
> 
> While loop {
>   mutex_lock
>   state cond <--this is where the thread supposedly waits (does this have 
> to be "while" loop or a simple if will do as is the case in my code?)
>   do something
>   mutex_unlock
> }
> Thread exit

This looks about right. You need to aquire the lock before calling
pthread_cond_wait() which then release the lock, waits for the condition
to be signaled and acquires the lock again.

Read the first paragraph of `man 3 pthread_cond_wait`

..what could however happen is that pthread_cond_wait() returns with an
error, without acquiring the lock!

HTH,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] question about multithreaded externals in Pd

[Robin Gareus]

Hi Ico,

just quick:

pthread_create() returns after the thread context has been created; but
the actual thread-function is not run directly.

The main function may continue before the actual thread is run.

In your case the pd_cwiid_doConnect() can be called before the
pd_cwiid_pthreadForAudioUnfriendlyOperations() enters the while() loop.

That seems to be a problem - it's too much code to dig though for me at
the moment to tell why this is so -  but since usleep() seems to solve
the issue, it probably is. (quick check: does it also crash if you
usleep() after the if (argc==2) {}; just before the return(x); ?

`man 3 pthread_yield` is better that usleep(). it's basically a
usleep(minimum-time-needed-to-run-other-threads).

Another option is to wait after thread-creation in the parent on a
barrier or lock that is released by the child-thread when it starts.

2c,
robin

On 10/02/10 02:36, Ivica Ico Bukvic wrote:
> Hi all,
> 
> I am wondering if anyone can shed some light on the following
> predicament. I am by no means a multi-threading guru so any insight
> would be most appreciated.
> 
> The following are relevant excerpts from the code of an external. AFAIK
> the external initializes mutex and cond and spawns a secondary worker
> thread that deals with audio-unfriendly (xrun-causing) write operations
> to the wiimote and terminates it when the object is destructed waiting
> for the thread to join back and then destroying the mutex.
> 
> Now, if I add a bit of usleep right after the thread has been spawned as
> part of the constructor (as included below) the external seems very
> stable (e.g. cutting and pasting it as fast as keyboard allows, or in
> other words constructing and destructing instances of it as fast as
> possible does not result in a crash). Yet, when one does not use usleep
> right after spawning the secondary (worker) thread in the constructor,
> the whole thing is very crash-prone, almost as if the spawning of thread
> does not go well unless given adequate time to do get things all into
> sync, so to say, even though this makes to me no sense as the way I
> understand it the constructor does not move ahead until pthread_create
> does not return a value (which in this case I am not bothering to read).
> 
> Curiously, when not using usleep, a crash may occur right at creation
> time, at any point while the object exists, and even as late as during
> its destruction. Any ideas?
> 
> P.S. I am also including the entire file for those interested in trying
> it out.
> 
> Best wishes,
> 
> Ico
> 
> Relevant excerpts (in random order and incomplete to allow for greater
> legibility):
> 
> //struct defining the object
> typedef struct _wiimote
> {
>   t_object x_obj; // standard pd object (must be first in struct)
> 
>   ...
>   
>   //Creating separate threads for actions known to cause sample drop-outs
>   pthread_t unsafe_t;
>   pthread_mutex_t unsafe_mutex;
>   pthread_cond_t unsafe_cond;
> 
>   t_float unsafe;
> 
>   ...
> 
>   t_float led;
> 
>   ...
> 
> } t_wiimote;
> 
> 
> //constructor
> static void *pd_cwiid_new(t_symbol* s, int argc, t_atom *argv)
> {
>   ...
> 
>   x->led = 0;
> 
>   // spawn threads for actions known to cause sample drop-outs
>   threadedFunctionParams rPars;
>   rPars.wiimote = x;
>   pthread_mutex_init(&x->unsafe_mutex, NULL);
>   pthread_cond_init(&x->unsafe_cond, NULL);
>   pthread_create( &x->unsafe_t, NULL, (void *)
> &pd_cwiid_pthreadForAudioUnfriendlyOperations, (void *) &rPars);
> 
>   //WHY IS THIS NECESSARY? I thought that pthread_create call will first
> finish spawning thread before proceeding
>   usleep(100); //allow thread to sync (is there a better way to do this?)
>   
>   ...
> }
> 
> //destructor
> static void pd_cwiid_free(t_wiimote* x)
> {
>   if (x->connected) {
>   pd_cwiid_doDisconnect(x); //this one has nothing to do with 
> thread but
> rather disconnects the wiimote
>   }
> 
>   x->unsafe = -1; //to allow secondary thread to exit the while loop
> 
>   pthread_mutex_lock(&x->unsafe_mutex);
>   pthread_cond_signal(&x->unsafe_cond);
>   pthread_mutex_unlock(&x->unsafe_mutex);
> 
>   pthread_join(x->unsafe_t, NULL);
>   pthread_mutex_destroy(&x->unsafe_mutex);
> 
>   ...
> }
> 
> //worker thread
> void pd_cwiid_pthreadForAudioUnfriendlyOperations(void *ptr)
> {
>   threadedFunctionParams *rPars = (threadedFunctionParams*)ptr;
>   t_wiimote *x = rPars->wiimote;
>   t_float local_led = 0;
>   t_float local_rumble = 0;
>   unsigned char local_rpt_mode = x->rpt_mode;
> 
>   while(x->unsafe > -1) {
>   pthread_mutex_lock(&x->unsafe_mutex);
>   if ((local_led == x->led) && (local_rumble == x->rumble) &&
> (local_rpt_mode == x->rpt_mode)) {
>   pthread_cond_wait(&x->unsafe_cond, &x->unsafe_mutex);
>   }
> 
>   if (local_

[PD] [ANN] Linux Audio Conference 2011

[Robin Gareus]

sorry for x-posting.


Dear Linux Audio developer, user, composer, musician, philosopher
and anyone else interested, you are invited to the...

Linux Audio Conference 2011
The Open Source Music and Audio Software Conference

May 6-8 2011
Music Department, National University of Ireland, Maynooth
Maynooth, Co.Kildare, Ireland
http://music.nuim.ie

As in previous years, we will have a full programme of talks,  workshops
and music.
Two calls will be issued, a Call for Papers (see below) and Call for
Music (soon to be announced).

Further information will be found in the LAC2011 website (under
construction).

 CALL FOR PAPERS =

Papers on the following categories (but not limited to them) are now
invited for submission:

* Ambisonics
* Education
* Live performance
* Audio Hardware Support
* Signal Processing
* Music Composition
* Audio Languages
* Sound Synthesis
* Audio Plugins
* MIDI
* Music Production
* Linux Kernel
* Physical Computing
* Interface Design
* Linux Distributions
* Networked Audio
* Video
* Games
* Media Art
* Licensing

We very much welcome practical papers resp. software demos ("how I use
Linux Audio applications to create my music/media art").

Paper length: 4-8 pages, with abstract (50-100 words) and up to 5  keywords.
Language: English.
The copyright of the paper remains with the author, but we reserve the
right to create printed proceedings from all submitted (and accepted)
papers.

IMPORTANT DATES:
Submission deadline: 15/January 2011
Notification of acceptance: 7/March 2011
Camera-ready papers: 1/April 2011

Queries: Victor Lazzarini, NUI Maynnooth (victor.lazzar...@nuim.ie)

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [LAD] Paul's Extreme Sound Stretch

[Robin Gareus]

On Oct 1, 2010, at 2:32 AM, Camilo Polymeris wrote:

>> The original Fourier Transform as invented by the smart French
>> guy of the same name does operate on continuous (as opposed to
>> sampled) data from -inf to +inf.
> 
> I understand Fourier invented the Fourier Series "only", anyone knows
> who generalized it to FT?

not me,  but google did:

"Fourier’s initial series lacked the precision of a function, and Dirichlet and 
Riemann would later express the series as a formal integral." [1]

and 

"The first fast Fourier transform (FFT) algorithm for the DFT was discovered 
around 1805 by Carl Friedrich Gauss.." [2]

[1] 
http://www.k-grayengineeringeducation.com/blog/index.php/2007/12/21/engineering-education-today-in-history-blog-fourier-series-introduced/

[2] http://en.wikipedia.org/wiki/Fourier_analysis#History


> And yes, I think the FT isn't so hard to understand, and a pretty
> useful concept. FFT, on the other hand... never really tried.
> 

Sometimes I regret that I skipped most of the group theory lectures (I still 
have a very different idea what "group-theory" should be about) but I stopped 
worrying: libfftw [3] is pretty well documented, comes with a good manual and a 
tutorial.

Unless you're really into maths and numerics you'll probably learn nothing 
useful. That might be actually the reason why DFT algorithms have been 
re-invented or re-discovered  a couple of times during history: 1805, 1965, 
1984 [4].
If I may suggest: read up on DFT and leave FFT to the the maths geeks.

[3] http://www.fftw.org/

[4] 
http://en.wikipedia.org/wiki/Fast_Fourier_transform#Cooley.E2.80.93Tukey_algorithm

Cheers!
robin

> Greetings
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Paul's Extreme Sound Stretch

[Robin Gareus]

On Sep 30, 2010, at 11:16 PM, f...@kokkinizita.net wrote:

> On Thu, Sep 30, 2010 at 09:23:08PM +0200, Robin Gareus wrote:
> 
>> Back when I was introduced to FT in some Physics lecture I was happy
>> that I was able to use it and completely forgot to check the history :)
>> Probably related to why I favored experimental Physics over Theory.
> 
> If you're still living in Paris, make sure to visit the 'Musée des
> Arts et Métiers' one day. Quite a nice place for vintage experimental
> physics. It's also the place where the final mad scene of Umberto Eco's 
> novel "Foucault's Pendulum" is situated. The pendulum itself used to be
> there, but it's now at the Panthéon.
> 

I know the latter of course, but I've not yet been to the Musee des Arts et 
Metiers. 
Thanks for the hint, I'll definitely schedule a visit.

There's so many hidden treasures here in plain sight one hardly knows where to 
start.


>>> And I guess this is where the windowing comes in. Calculate the spectrum
>>> of small pieces instead.
>>> 
>> correct.
>> 
>> Furthermore there are different kind of windows (here a window refers to
>> a block of audio-samples) and windows can overlap. That's where it gets
>> complicated.
> 
> Even windows won't save you from apparent madness. Imagine a signal
> consisting of all zero samples, except one every second which has
> value 1. Such a signal contains all frequencies that are a multiple 
> of 1 Hz, up to half the sample frequency. Those frequencies are present
> all the time. Now take a window of say half a second. If it includes a
> pulse you get more or less the same spectrum again. If it doesn't, you
> get nothing... even if the frequencies should be there :-)
> 

to come back to the beginning: that's why paulstretch does allow to specify the 
window size.

Cheers!
robin


> Ciao,
> 
> -- 
> FA
> 
> There are three of them, and Alleline.
> 

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Paul's Extreme Sound Stretch

[Robin Gareus]

On 09/30/10 22:41, Philipp Überbacher wrote:
> Excerpts from Robin Gareus's message of 2010-09-30 16:21:27 +0200:
>> On 09/30/10 13:35, Louigi Verona wrote:
>>> As for JACK support would anyone be interested in adding it, if it is
>>> trivial? Would love to have it in my audio chain.
>>
>> At second glance: it's not going to be that easy. The built-in player
>> makes use of mutex-locks which would need to be replaced with a
>> [lock-free] ringbuffer (Adding JACK I/O is still trivial but without
>> lock-free buffers paulstrech would be able to block jack-processing and
>> cause x-runs).
>>
>>
>> That'd be a good job for someone who wants to get started with JACK and
>> C/C++ programming.
> 
> I'd be interested.
> 
> It would likely take me some time though, and maybe some guidance, but
> it's something I want to learn. I dabbled in C but can only read simple
> code. I start to study computer science next week, which will give me
> access to the library at least, to K&R and a bunch of others.
> The lectures at university are mostly in java but C is required at some
> point, and I guess it's better to start learning it sooner rather than
> later, besides, it seems to be needed for all the neat audio stuff ;)
> 
> So yeah, I guess I should get the code, put it in a git repo and just
> start hacking...

Aww sorry. I saw this too late.

The film I intended to watch was too boring so..

  git clone git://rg42.org/paulstretch
  cd paulstretch
  ./compile_linux_fftw_jack.sh

or get a diff:
http://rg42.org/gitweb/?p=paulstretch.git;a=commitdiff_plain;hp=upstream;h=master


There's still quite a few things to do. besides: it's a quick hack and
far from optimal:

  - It currently only opens the JACK clients if it's playing.
(after stop the port-connections are lost)
  - It auto-connects the jack-ports to the first two available outputs
(unless you remove the -DENABLE_AUTOCONNECT_JACK compile option)
  - it does not do any resampling
(but prints a warning if the samplerates mismatch and plays anyway)
  - it does not add a ringbuffer.
(it may cause x-runs)

So you can take this as inspiration :)


Using a jack_ringbuffer is actually not that hard, have a look at the
jack_capture.c example client (comes with the jackd source).

Resampling with libsamplerate is not very complicated, although I'm sure
you'll have to work out a few things if you do it the first time (it's a
good learning experience - google for "secret rabbit code".
OTOH I'm not convinced that the paulstrech player needs anyway. It may
be a nice add-on feature though.

Hint: for both ringbuffer and/or resampling you'll want to add a new
function to Player.cpp that basically does the same as

 void Player::getaudiobuffer(int nsamples, float *out)

I suggest
  getaudiobuffer_channel(int nsamples, int channel, float *out)

Contact Paul and Alan Calvin :)

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Paul's Extreme Sound Stretch

[Robin Gareus]

On 09/30/10 20:49, Philipp Überbacher wrote:
> Excerpts from fons's message of 2010-09-30 14:29:01 +0200:
>> On Thu, Sep 30, 2010 at 01:53:44PM +0200, Robin Gareus wrote:
>>
>>>> Q: Can anyone explain the FFT in simple terms ?
>>>> A. No.
>>>
>>> LOL.
>>>
>>> basically, Fourier proved that any signal can be represented a sum of
>>> sine-waves.
>>>
>>> (well, that's not entirely true: it needs to be a periodic signal, but
>>> the period length can approach infinity...)
>>>
>>> FFT is "just" the implementation of that theorem (or Principle?!)
>>
>> The original Fourier Transform as invented by the smart French
>> guy of the same name does operate on continuous (as opposed to 
>> sampled) data from -inf to +inf. The 'spectrum' interpretation
>> came later. It was originally a mathematical tool used to find
>> integrals of functions that would be impossible to integrate in
>> closed form, and Fourier himself used it to study the propagation
>> of heat in solids. 

Thanks a lot for this comprehensive history lesson.

Back when I was introduced to FT in some Physics lecture I was happy
that I was able to use it and completely forgot to check the history :)
Probably related to why I favored experimental Physics over Theory.

>> The DFT (Discrete FT) is the same thing operating on sampled 
>> signals. It is usually also limited in time.
>>
>> The FFT (Fast FT) is an algorithm to compute a finite-length
>> DFT very efficiently.
>>
>> The 'spectrum' interpretation is really quite ambiguous.
>>
>> You could take the DFT of e.g. a complete Beethoven symphony.
>> The result is the 'spectrum' and in theory this is fixed over
>> infinite time - the frequencies that are present according to
>> this spectrum are there *all the time*. But that is not how
>> we would perceive the music - we do not hear a constant mash
>> of all frequencies, the spectrum as we hear it changes over
>> time.
>>
>> Ciao,
>>
>> -- 
>> FA
>>
>> There are three of them, and Alleline.
> 
> And I guess this is where the windowing comes in. Calculate the spectrum
> of small pieces instead.
>
correct.

Furthermore there are different kind of windows (here a window refers to
a block of audio-samples) and windows can overlap. That's where it gets
complicated.

The most commonly known window shapes are Rectangular window, Gaussian ,
Hann- and Hamming windows (the last two are cosine shapes) which allow
to avoid discontinuities when processing blocks.

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Paul's Extreme Sound Stretch

[Robin Gareus]

On 09/30/10 20:52, Philipp Überbacher wrote:
> Excerpts from Louigi Verona's message of 2010-09-30 09:01:24 +0200:
>> Hey guys!
>>
>> I have two questions.
>>
>> 1. How does Sound Stretch work? It is incredible the way it can produce a
>> tone which has no noticeable vibrations, just a wall of sound. How is that
>> accomplished, in layman terms if possible :)
>> 2. Can this program be jackified and is that a lot of work?
> 
> How the heck did you get it to build? It's been how many years since the
> last release?

~1.5y - April 2009.

add
#include 
to the top of Input/MP3InputS.cpp
and run
  ./compile_linux_fftw.sh


best,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Paul's Extreme Sound Stretch

[Robin Gareus]

On 09/30/10 13:35, Louigi Verona wrote:
> As for JACK support would anyone be interested in adding it, if it is
> trivial? Would love to have it in my audio chain.

At second glance: it's not going to be that easy. The built-in player
makes use of mutex-locks which would need to be replaced with a
[lock-free] ringbuffer (Adding JACK I/O is still trivial but without
lock-free buffers paulstrech would be able to block jack-processing and
cause x-runs).


That'd be a good job for someone who wants to get started with JACK and
C/C++ programming.


I don't know if Nasca Octavian Paul is subscribed to this list and if
he's still actively developing it; but it would be the best to ask him
first.

The missing ringbuffer is most likely the cause of the already known bug
"sometimes the playback is choppy" listed at the bottom of
http://hypermammut.sourceforge.net/paulstretch/


If no-one else volunteers I could do it to take get my mind off things
during some short-distance flights next week-end.

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Paul's Extreme Sound Stretch

[Robin Gareus]

On 09/30/10 13:15, Dave Phillips wrote:
> Robin Gareus wrote:
>>
>> In layman terms:
>>
>> There's a smart French guy by the name of Joseph F. sitting inside it:
>> If you play him some audio: He thinks: "Hey, this is actually just a few
>> simple sine-waves added together (superpositioned)", he quickly
>> calculates their frequencies and amplitudes and asks "Now, you want to
>> change the duration?" easy: "I'll generate some new sine-waves with
>> these frequencies and amplitudes, how long did you say you want?"
>>
>> (The smart thing about this French guy is that he actually speaks fluent
>> English - Sorry I could not resist :)
>>   
> 
> I recall a brief exchange on a DSP list that went something like this:
> 
> Q: Can anyone explain the FFT in simple terms ?
> A. No.

LOL.

basically, Fourier proved that any signal can be represented a sum of
sine-waves.

(well, that's not entirely true: it needs to be a periodic signal, but
the period length can approach infinity...)

FFT is "just" the implementation of that theorem (or Principle?!)

> I have read and understood some articles and descriptions of the FFT.
> Mark Dolson's original article on the phase vocoder (in the Computer
> Music Journal V10,#4, Winter 1986), is still a good introduction for
> computer-based musicians, though it may be a bit too technical by
> contemporary standards.
> 
> Louigi, take a look at some descriptions of what an FFT does. It does
> use "windows" but you'll have to do some homework to find out what's
> meant by the term in this context.
> 
> http://en.wikipedia.org/wiki/FFT
> 
> Beware, that page is a maths page, it's not directly concerned with the
> use of the FFT in music/sound applications.

It may help to make some connection with the equations on
http://en.wikipedia.org/wiki/Fourier_transform if you know that

  sin (x) = ImaginaryPartOf ( e^(i x) )
  cos (x) = RealPartOf ( e^(i x) )
  where i = sqrt(-1);

> And btw, I agree wrt Paul's Extreme Stretch, it's a great tool.

It is indeed. Kudos to Paul.


FWIW, http://arss.sourceforge.net/ works similarly. It provides
sound-to-image and image-to-sound functionality using FFT.

You can also use it to do time-stretching but it's actually more fun to
toy around with it: http://arss.sourceforge.net/examples.shtml


> Best,
> 
> dp
> 
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Paul's Extreme Sound Stretch

[Robin Gareus]

On 09/30/10 09:40, Patrick Shirkey wrote:
> 
> On Thu, September 30, 2010 12:01 am, Louigi Verona wrote:
>> Hey guys!
>>
>> I have two questions.
>>
>> 1. How does Sound Stretch work? It is incredible the way it can produce a
>> tone which has no noticeable vibrations, just a wall of sound. How is that
>> accomplished, in layman terms if possible :)
> 
> It grabs a section of the audio and copies/multiplies it then appears to
> apply some pretty neat math to smooth it all out funnily enough using a
> selection of windows to get the best result.

Are you sure? Where did you get that info from?

Just skimming over Stretch.cpp gives me the impression that it's based
on Fourier analysis and re-sythesis.
http://en.wikipedia.org/wiki/Fourier_analysis

The process() loop looks like:
{
  apply_window();
  smp2freq(); // Fourier Analysis
  process_spectrum();
  freq2smp(); // Fourier Synth
}

In layman terms:

There's a smart French guy by the name of Joseph F. sitting inside it:
If you play him some audio: He thinks: "Hey, this is actually just a few
simple sine-waves added together (superpositioned)", he quickly
calculates their frequencies and amplitudes and asks "Now, you want to
change the duration?" easy: "I'll generate some new sine-waves with
these frequencies and amplitudes, how long did you say you want?"

(The smart thing about this French guy is that he actually speaks fluent
English - Sorry I could not resist :)

> 
>> 2. Can this program be jackified and is that a lot of work?
>>
> 
> It uses portaudio. Doesn't that have a jack output?

Yes, but its implementation is not very well done.

> Otherwise yes, he has designed it so that adding jack support would be
> fairly trivial.
> 

Indeed, to change the integrated player to output to JACK would be
trivial. It currently uses the PortAudio's StreamCallback which is very
similar to JACK's process callback.

Using it to do "live" timestreching with JACK (jack-in -> jack-out) is
AFAICT impossible because:


If you feed it N samples (or seconds) of audio you end up with M samples
(or seconds) with  M > N.

One could do a kludge:
eg. for a 1:10 time stretch with continuous output:
  - read 1 sec of audio from the input
  - ignore 9 secs of the input
but I don't think this will be useful.


best,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [oauth] twitter and liboauth problems

[Robin Gareus]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Jack,

Two things: Twitter requires you to use HTTP-POST instead of GET.
see http://dev.twitter.com/doc/post/statuses/update
(I don't have much experience with twitter myself, but from what I
gathered their error message "incorrect signature" may be misleading and
applies to other errors as well.)

You also need to sign the URL _with_ the status query parameter alike:

char *postargs;
char myurl[1024];
sprintf(myurl, "%s?status=%s", update_url, "newstatus");

req_url = oauth_sign_url2(myurl, &postargs, OA_HMAC, NULL,
 customerKey, customerSecret,
 access_token, access_token_secret);

response = oauth_http_post(req_url,postargs);

if (postargs) free(postargs);

HTH,
robin


On 09/19/10 13:28, jack wrote:
> I wrote a twitter client use C, I want test make a  tweet, but when I
> send the strings XML returned "incorrect signature", I hope someone
> can tell me how to do.
> 
> Code:
> 
> 
> #include 
> #include 
> #include 
> #include 
> #include "urlcode.h"
> 
> int main(void)
> {
>const char
>   *customerKey   = "ZjDRxcsmKBth8i4oxuNy9g",
>   *customerSecret= "GDpuZhrMDlVwkWOSpsz2F8tBPOIEYdEXCNI91033D0";
>char *req_url;
>const char *access_token="32941837-
> J2ldWeUcO2rejBG1CE1kzVoMIBfzzK6j77k9Db2ib",
>   
> *access_token_secret="MgvUTgzSnlKFgLzJXx65TPI4uqi348IabnoqxQtbvI";
> 
>char *update_url="http://api.twitter.com/1/statuses/update.xml";;
>char *sig_url;
>char *response;
> 
>req_url = oauth_sign_url2(update_url, NULL, OA_HMAC, NULL,
> customerKey, customerSecret,
>  access_token,access_token_secret);
>printf("Post: %s\n", req_url);
> 
>char *newurl = oauth_catenc(2, req_url, "status=test");
>printf("%s\n", newurl);
>char *url = oauth_url_unescape(newurl, NULL);
>url = oauth_url_escape(url);
>printf("%s\n", url);
> 
> 
>sig_url = malloc(2+strlen(newurl));
>sprintf(sig_url, "%s\n", newurl);
> 
>response = oauth_http_get(req_url,NULL);
> 
>printf("user_timeline xml data:\n%s\n", response);
> 
>if(sig_url) free(sig_url);
>if(response) free(response);
>return 0;
> 
> }
> 
> Thanks.
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkyc/J0ACgkQeVUk8U+VK0JOowCgpTuz4c7NHbhzU2nBPws0CFyz
DIYAoLAWlfoF6NfCpk1Zi9kfiXGk9OME
=6Bz9
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oa...@googlegroups.com.
To unsubscribe from this group, send email to 
oauth+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/oauth?hl=en.

Re: [oauth] about twitter

[Robin Gareus]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/23/10 03:18, Robin Gareus wrote:
> On 09/10/10 16:57, Lee Mr wrote:
>> I wrote a twitter client with llib, but I do not know how to pass
>> parameters.
>> This is my codes:
>> char *update_url="http://api.twitter.com/1/statuses/update.xml";;
>> req_uri = oauth_sign_url2(update_url, NULL, OA_HMAC, NULL,
>> customerKey, customerSecret,access_token,access_token_secret);
>> char *response = oauth_http_get(req_uri,NULL);
> 
> 
>> I want update my twitter, but return error.
> 
> http://dev.twitter.com/doc/post/statuses/update
> says  "Supported request methods: POST"
> 
> char *postargs = NULL;
> req_uri = oauth_sign_url2(update_url, &postargs, OA_HMAC, NULL,
> customerKey, customerSecret,access_token,access_token_secret);
> char *response = oauth_http_post(req_uri,postargs);
> if (postargs) free(postargs);
> 
> HTH,
> robin

Oh and as Lasantha pointed out: your update_url needs to include a
status parameter:

char *update_url="http://api.twitter.com/1/statuses/update.xml?status=";;

ciao,
robin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkyaq6cACgkQeVUk8U+VK0K3NgCgtlyOhS/Y0Jkjk99Q5qk/m+Jr
2LwAnRj5InFqXoPbtYvrWAanpGgS+og8
=i6n5
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oa...@googlegroups.com.
To unsubscribe from this group, send email to 
oauth+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/oauth?hl=en.

Re: [oauth] about twitter

[Robin Gareus]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/10/10 16:57, Lee Mr wrote:
> I wrote a twitter client with llib, but I do not know how to pass
> parameters.
> This is my codes:
> char *update_url="http://api.twitter.com/1/statuses/update.xml";;
> req_uri = oauth_sign_url2(update_url, NULL, OA_HMAC, NULL,
> customerKey, customerSecret,access_token,access_token_secret);
> char *response = oauth_http_get(req_uri,NULL);
> 
> 
> I want update my twitter, but return error.

http://dev.twitter.com/doc/post/statuses/update
says  "Supported request methods: POST"

char *postargs = NULL;
req_uri = oauth_sign_url2(update_url, &postargs, OA_HMAC, NULL,
customerKey, customerSecret,access_token,access_token_secret);
char *response = oauth_http_post(req_uri,postargs);
if (postargs) free(postargs);

HTH,
robn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkyaqvgACgkQeVUk8U+VK0JqwwCgkiCLbNbKElY8hMIhCnT46oU9
0JYAoKB22sBWJ9n70PY2dC1ee4A8lMzM
=jq1w
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oa...@googlegroups.com.
To unsubscribe from this group, send email to 
oauth+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/oauth?hl=en.

Re: [LAD] Basic Question: SND/SOUND Libraries Seem to be Missing

[Robin Gareus]

On 09/12/2010 09:17 PM, Rory Filer wrote:
> Hello,
> 
> Let me point out in advance that my problem is pretty trivial compared to
> most of the postings on that list. If a journey in sound engineering on
> Linux is 1000 steps, I'm at step 1 here. I basically tried configuring sound
> into the kernel but it didn't seem to work. If you think you can help,
> please read on. Otherwise, stop here.
> 
> And thanks to all who continue from here...
> 
> I want to build sound support into my embedded Linux platform (2.6.28); the
> CPU supports I2S in silicon, but I haven't got a driver for that yet. My
> plan is to build the kernel with SOUND/SND configurations enabled and start
> working on the driver later. In my configurations, I've left all the sound
> card-specific options out, keeping just the CONFIG_SND_SOC. I thought it
> would be sufficient to install snd-dummy so that any cross-compiled audio
> applications could be fooled into working. l rebuilt the kernel after *make
> clean* and noted several new SND files being compiled. So far so good. The
> final zImage was only a little larger. Overall, the configuration and build
> seemed to be going through all the right motions, but when I loaded zImage
> onto the target I didn't see any bootup logging that suggested audio was now
> working. As an experiment, I tried to insmod snd_dummy.ko but got a long
> list of errors. I guess I'm missing something basic.
> 
> Here's my configuration choices:
> 
>> CONFIG_SOUND=m
>> CONFIG_SOUND_OSS_CORE=y
>> CONFIG_SND=m
>> CONFIG_SND_TIMER=m
>> CONFIG_SND_PCM=m
>> # CONFIG_SND_SEQUENCER is not set
>> CONFIG_SND_OSSEMUL=y
>> CONFIG_SND_MIXER_OSS=m
>> CONFIG_SND_PCM_OSS=m
>> CONFIG_SND_PCM_OSS_PLUGINS=y
>> # CONFIG_SND_DYNAMIC_MINORS is not set
>> CONFIG_SND_SUPPORT_OLD_API=y
>> CONFIG_SND_VERBOSE_PROCFS=y
>> # CONFIG_SND_VERBOSE_PRINTK is not set
>> # CONFIG_SND_DEBUG is not set
>> CONFIG_SND_DRIVERS=y
>> # CONFIG_SND_PCSP is not set
>> CONFIG_SND_DUMMY=m
>> # CONFIG_SND_MTPAV is not set
>> # CONFIG_SND_MTS64 is not set
>> # CONFIG_SND_SERIAL_U16550 is not set
>> # CONFIG_SND_MPU401 is not set
>> # CONFIG_SND_PORTMAN2X4 is not set
>> # CONFIG_SND_ISA is not set
>> # CONFIG_SND_PCI is not set
>> # CONFIG_SND_SPI is not set
>> # CONFIG_SND_USB is not set
>> # CONFIG_SND_PCMCIA is not set
>> CONFIG_SND_SOC=m
>> CONFIG_SND_SOC_ALL_CODECS=m
>> CONFIG_SND_SOC_AD73311=m
>> CONFIG_SND_SOC_AK4535=m
>> CONFIG_SND_SOC_CS4270=m
>> CONFIG_SND_SOC_SSM2602=m
>> CONFIG_SND_SOC_TLV320AIC23=m
>> CONFIG_SND_SOC_TLV320AIC26=m
>> CONFIG_SND_SOC_TLV320AIC3X=m
>> CONFIG_SND_SOC_UDA1380=m
>> CONFIG_SND_SOC_WM8510=m
>> CONFIG_SND_SOC_WM8580=m
>> CONFIG_SND_SOC_WM8731=m
>> CONFIG_SND_SOC_WM8750=m
>> CONFIG_SND_SOC_WM8753=m
>> CONFIG_SND_SOC_WM8900=m
>> CONFIG_SND_SOC_WM8903=m
>> CONFIG_SND_SOC_WM8971=m
>> CONFIG_SND_SOC_WM8990=m
>> # CONFIG_SOUND_PRIME is not set
>>
> 
> And here is the list of errors from installing snd-dummy.ko
> 
> [r...@127 drivers]#insmod snd-dummy.ko
> Using snd-dummy.ko
> snd_dummy: Unknown symbol snd_pcm_lib_free_pages
> snd_dummy: Unknown symbol snd_pcm_set_ops
> snd_dummy: Unknown symbol snd_ctl_boolean_stereo_info
> snd_dummy: Unknown symbol snd_card_new
> snd_dummy: Unknown symbol snd_pcm_lib_ioctl
> snd_dummy: Unknown symbol snd_pcm_lib_malloc_pages
> snd_dummy: Unknown symbol snd_pcm_lib_preallocate_pages_for_all
> snd_dummy: Unknown symbol snd_card_free
> snd_dummy: Unknown symbol snd_ctl_add
> snd_dummy: Unknown symbol snd_pcm_new
> snd_dummy: Unknown symbol snd_pcm_suspend_all
> snd_dummy: Unknown symbol snd_pcm_period_elapsed
> snd_dummy: Unknown symbol snd_card_register
> snd_dummy: Unknown symbol snd_pcm_format_set_silence
> snd_dummy: Unknown symbol snd_pcm_format_width
> snd_dummy: Unknown symbol snd_ctl_new1
> insmod: cannot insert `snd-dummy.ko': Unknown symbol in module (-1): No such
> fil
> e or directory
> 
> Best Regards,
> 
> Rory

Hi Rory,

You're not missing a library but some other kernel modules which provide
those symbols.

IIRC the snd-dummy modules requires 'snd_pcm' and 'snd'.

After installing the kernel, run 'depmod' and try to load the module
with 'modprobe snd-dummy' instead of 'insmod snd-dummy.ko'.

See the man-page for modprobe and depmod for details.

HTH,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [oauth] Does liboauth support noblock IO?

[Robin Gareus]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/10/2010 11:18 AM, Weibin Yao wrote:
> I find the oauthexample.c is a block IO example, is there a no-block
> IO example?

Short answer: No, but there is libcurl example code for this.

Basically libOAuth only handles the OAuth part (parameter encoding,
signing), however it [optionally] includes a few convenient wrappers
around libcurl.

The HTTP/curl integration in libOAuth is very simple, it also does not
do any error handing and is basically just curl-example code.

It's very easy to to use [lib]curl directly.


One option for non-blocking requests with libOAuth is to simply start a
thread for the HTTP request. 'oauth_post_data_with_callback()' also
allows to update a progress-bar as the request is executed...

C++ code using pthreads would look like this:

- --8<---
extern "C" {
#include 
#include 
}

void *http_get_thread (void *arg) {
  MyClass *m = static_cast(arg);

  /* optional - if you'd like to be able to abort
 the request with pthread_cancel() */
  pthread_setcancelstate(PTHREAD_CANCEL_ENABLE,NULL);
  pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);

  char *res = oauth_http_get2(m->signed_req_url, NULL, NULL);

  /* optional : don't allow to abort once the request
 is finished and we're processing the returned data */
  pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);

  m->http_download_done(res);

  pthread_exit(0);
  return 0;
}

void
MyClass::http_download_done (char *data){
  if (!data) { /* HTTP status != 200 */ return; }
  /* do something - still in background thread context. */
  free(data);
}

void
MyClass::launch_http_request() {
  pthread_create(&thread_id_tt, NULL, http_get_thread, this);
}
- --8<---

HTH,
robin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkyLvwoACgkQeVUk8U+VK0LlaACgsiazvCjX4C5JqXYDues3Kr7/
QckAoKgPv5VgoruOyxfC6U43fc/B+NZu
=w9rb
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oa...@googlegroups.com.
To unsubscribe from this group, send email to 
oauth+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/oauth?hl=en.

Re: [oauth] liboauth minor fixes

[Robin Gareus]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Fret.

On 09/03/2010 07:38 AM, fret wrote:
> I downloaded and compiled liboauth with a view towards using it in
> some email software. I made some simple changes to make it compile
> nicely on VC6:

Many Thanks. I'll apply them.

I also just noticed: [V]I not only messed up the indenting but there's a
typo in the function name: independent lacks a 'd'. stay tuned.

Cheers!
robin


> Index: src/oauth.c
> ===
> --- src/oauth.c   (revision 1238)
> +++ src/oauth.c   (working copy)
> @@ -863,12 +863,18 @@
>   *
>   * returns 0 (false) if strings are not equal, and 1 (true) if
> strings are equal.
>   */
> -int oauth_time_indepenent_equals_n(const char* a, const char* b,
> size_t len_a, size_t len_b) {
> - if (a == NULL) return (b == NULL);
> - else if (b == NULL) return 0;
> - else if (len_b == 0) return (len_a == 0);
> -  int diff = len_a ^ len_b;
> - int i,j = 0;
> +int oauth_time_indepenent_equals_n(const char* a, const char* b,
> size_t len_a, size_t len_b)
> +{
> + int diff, i, j;
> + if (a == NULL)
> + return (b == NULL);
> + else if (b == NULL)
> + return 0;
> + else if (len_b == 0)
> + return (len_a == 0);
> +
> + diff = len_a ^ len_b;
> + i,j = 0;
>   for (i=0; i   diff |= a[i] ^ b[j];
>   j = (j+1) % len_b;
> Index: src/oauth.h
> ===
> --- src/oauth.h   (revision 1238)
> +++ src/oauth.h   (working copy)
> @@ -643,7 +643,7 @@
>   * Multiple header elements can be passed separating them with "\r\n"
>   * @return returned HTTP reply or NULL on error
>   */
> -char *oauth_post_file (const char *u, const char *fn, size_t len,
> const char *customheader);
> +char *oauth_post_file (const char *u, const char *fn, const size_t
> len, const char *customheader);
> 
>  /**
>   * http post raw data
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkyI/AYACgkQeVUk8U+VK0IcHgCeIYO1ZYSRroSc/wf8J5Kitsij
ZugAoJ7a7dqhm7ojsqaWIthKEpgcIBj/
=38Xv
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oa...@googlegroups.com.
To unsubscribe from this group, send email to 
oauth+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/oauth?hl=en.

Re: [LAD] wiki.linuxaudio.org, still help needed ?

[Robin Gareus]

On 08/16/2010 06:57 PM, Niels Mayer wrote:
> What about adding a more modern Wiki/CMS platform -- http://xwiki.org
> -- allowing WYSIWYG editing in your browser:
> http://platform.xwiki.org/xwiki/bin/view/Features/WysiwygEditor .
> Also, useful for public collaborative documentation, the new
> annotations feature:
> http://code.xwiki.org/xwiki/bin/view/Applications/AnnotationsApplication
> . Xwiki has  extensive import/export features. Aside from the usual
> export as pdf/html/print etc, you can also use Xwiki to run openoffice
> (in server mode) to import documents written in word/OOo/etc/ and
> easily convert them to wiki documents:
> http://code.xwiki.org/xwiki/bin/view/Applications/OfficeImporterApplication

Nice, but what would be the use-cases for those features on
linuxaudio.org? Basically we recommend flossmanuals.net for
collaborative documentation.

It'd also be a bit of work to [write a script to] convert the ~4000
existing wiki pages (mostly apps) to the xwiki; and write a custom app
(or plugin) to visualize tags/categories like eg.
http://wiki.linuxaudio.org/apps/categories/jack

Besides that, I'm somewhat averse to installing JAVA on the LAO server.

> It's quite a bit more than a wiki app, you can write applications with
> it as well. Here's some of mine:
> http://nielsmayer.com/xwiki/bin/view/Exhibit/NPRpods3
> (an earlier version:
> http://nielsmayer.com/xwiki/bin/view/Timeline/NprTimeline &&
> http://nielsmayer.com/xwiki/bin/view/Timeline/KcrwTimeline  before I
> switched to http://www.simile-widgets.org/exhibit/ e.g.
> http://nielsmayer.com/xwiki/bin/view/Exhibit/Presidents4 ).

Cool. However, I don't see the benefit of a Timeline for the
wiki.linuxaudio.org site. I think we'd rather want some more music
related features like f.i. http://wiki.linuxaudio.org/wiki/abc :) but
maybe that's just me.

best,
robin


> Niels
> http://nielsmayer.com
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] wiki.linuxaudio.org, still help needed ?

[Robin Gareus]

Hi Carlo,

Sorry late reply - I'm on holiday. Yes, the call is still actual.
We're looking for both: regular content maintainers, as well as help
with styling the site.

As for style: there best contender so far is the "experimental" Theme;
switch it at http://wiki.linuxaudio.org/wiki/user/rgareus
Alas it's unfinished and partly invalid CSS/JS to be cleaned up :/

If you have a good idea: Please make a mockup or outline it. The wiki is
a dokuwiki.org.

Please stay tuned. I'll be back online regularly around end of August.

Cheers!
robin

On 08/16/2010 01:54 PM, Carlo Ascani wrote:
> I just saw the announce on http://wiki.linuxaudio.org/
> "We are looking for front-end developers, web-designers and
> wiki-administrators to join in."
> 
> What kind of help do you need?
> I mean, different from editing wiki content.
> I could help with little graphics or web-design.
> 
> You could find me on freenode as 'carloratm'
> 
> Btw, i've just done these sites:
> http://gnufunk.org
> http://radio.gnufunk.org
> 
> 
> Cheers
> 
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [64studio-users] For the German consumer protection Linux multimedia doesn't exist

[Robin Gareus]

On 07/26/2010 04:27 PM, Brian Bergstrom wrote:
> Maybe this one flew over my head, but what is a 'hols'?
> -Brian

Holydays, maybe? Would at least fit into the context.

> 
> On 7/26/10 6:43 AM, Ralf Mardorf wrote:
>> N24 a news television channel is giving wrong information about video
>> editing software, the bad with it is, that even 'Stiftung Warentest', a
>> consumer protection organisation speaking on this television channel in
>> the news, just talked about Windows and that people need to buy, buy,
>> buy software and 'better' computers. They give concrete untrue
>> statements. It's because in Germany are hols and people usually film
>> their hols.

I don't own a TV for over 10 years now so I can't really comment on this
but: was there ever any TV channel that did not spread misinformation? :)

FWIW "Tageschau" (the news of the 'first german television channel' aka
ARD) is edited with Kino on Linux. AFAIK they even paid the Kino
developer for a while.

robin
___
64studio-users mailing list
64studio-users@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-users

Re: [LAD] twice as loud

[Robin Gareus]

On 07/25/2010 12:43 PM, Ralf Mardorf wrote:

> Just one question. Am I the only one who received a mail similar to this
> off-list:
> 
>>> [ yet more irrelvant mindless crap! ]
>>>
>>> How does the external ear exactly work? Perhaps it's part of this
>>> function, to reflect sound.
>>
>> Absolutely nothing to do with Linux Audio Development Ralf, ... please
> desist.
> 
> I sometimes receive mails off-list abusing me for mails other people did
> wrote.
> Here I did wrote this mail, but as a reply to this topic. So please, if
> you don't like me folks, abuse me for stuff that were my crime.


Hi Ralph,

Why are you writing to me? It might imply I did send you this email in
the first place. Even though I did not, I concur with the original
author although I'd like to phrase it differently:

Please ask only Linux audio hw/sw development related questions here.
When answering, please stick to your expertise. Stop guessing,
brainstorming and spreading FUD.

Joern formulated this once like this:
  /* before sending mail */
  if (i_know_what_im_talking_about()) {
send();
  } else {
discard();
sleep(3600);
  }

Some of your comments or OT discussions would have been better on LAU
(where most of the Devs are subscribed as well). I fail to see how you
are involved in developing any linux-audio application, so please
refrains from posting here.

As you can read on the description at http://linuxaudio.org/mailarchive/
"The linux-audio developer (LAD) mailing list is the place to discuss
and share in depth information concerning design, development and
architecture of linux audio related Hard- and Software. It's a fun place
to lure and learn. yet, take your time and think before posting there:
This is not the list to report generic linux audio bugs to developers."


Replying to your own emails N times and doing so quite often is not only
very bad netiquette, but annoying to many serious contributors here. If
you can't resist: write a blog.

Let me repeat an earlier advice which seems to have not sunken in:
Please read http://www.catb.org/~esr/faqs/smart-questions.html
in particular don't skip the "A wrong but authoritative-sounding answer
is worse than none at all." section.
and from http://tools.ietf.org/html/rfc1855 aka "Netiquette Guidelines":
"If you are caught in an argument, keep the discussion focused on
issues rather than the personalities involved."


To answer your question:
The list-admin for this email-list is Marc-Olivier Barre and he can be
reached at linux-audio-dev-ow...@lists.linuxaudio.org
If you want find out if an email went to the list, check the
list-archive: http://lists.linuxaudio.org/listinfo/linux-audio-dev

..or simply the email-header because IIRC the list does not accept
emails to it when it has been BCCed.

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Can someone add 2 features to Kluppe?

[Robin Gareus]

On 07/20/2010 02:46 PM, Patrick Shirkey wrote:
> On 07/20/2010 09:51 PM, Paul Davis wrote:
>> On Tue, Jul 20, 2010 at 7:48 AM, Patrick Shirkey
>>   wrote:
>>
>>   
>>>> A simple approach might be to just set a counter and have the
>>>> audio-process count it down (in audio-samples). Once it reaches zero:
>>>> play again.
>>>>
>>>>
>>>>
>>> The problem is how to set a counter that doesn't block the rest of
>>> the app
>>> while it is in process.
>>>  
>> i believe that robin's suggestion is the correct one. you don't want
>> to attempt audio timing using the system clock unless you have a
>> DLL/PLL that relates audio time to system time (and you don't).
>> decisions about what to do as time progresses need to be made in the
>> process() callback tree, not in the GUI or some other thread.
>> so just countdown some number of samples, and then resume playing, as
>> robin suggested. it won't block anything, anywhere.
>>
> 
> I don't have any problem with counting down using the audio clock but
> how do I translate that into seconds/milliseconds set in the ui?

see my other email.
You must be tired tonight :) Just multiply it by the sample-rate..

> At the moment the timer counts in seconds using this function
> 
> void *timer_thread(void *arg) {
> int how_long = *((int*) arg);
> sleep(how_long);
> pthread_mutex_unlock(&timer_lock);
> return NULL;
> }
> 
> While it is counting I set the volume for the per track playback buffer
> to zero. I also need to stop the playhead from moving but that is a
> seperate issue.
> 
> Ideally the timer should count in milliseconds which I guess is handled
> by changing the call to sleep to select instead?
> 
> ex.
> 
> void *timer_thread(void *arg) {
> int how_long = *((int*) arg);
> pause.tv_sec  = how_long;
> pause.tv_usec = 0;
> (void) select(0, 0, 0, 0, &pause);
> pthread_mutex_unlock(&timer_lock);
> return NULL;
> }

Either that, or use usleep(microseconds).

> I'm not sure how to do that with audio samples instead. Happy to make it
> work that way though if it is the best approach.

it is.

best,
robin

-- 
Robin Gareus   mail: ro...@gareus.org
site: http://gareus.org/   chat: xmpp:rgar...@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/

Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Can someone add 2 features to Kluppe?

[Robin Gareus]

On 07/20/2010 01:48 PM, Patrick Shirkey wrote:
> On 07/20/2010 06:54 PM, Robin Gareus wrote:
>> On 07/20/2010 09:17 AM, Patrick Shirkey wrote:
>>   
>>> On 07/20/2010 09:45 AM, Robin Gareus wrote:
>>> 
>>>> On 07/20/2010 01:06 AM, Louigi Verona wrote:
>>>>
>>>>   
>>>>> Hey guys!
>>>>>
>>>>> Some time ago I have asked someone to look into Kluppe and add a
>>>>> couple of
>>>>> features.
>>>>> My request was not ignored and Patrick Shirkey was kind enough to
>>>>> volunteer
>>>>> to try to help.
>>>>>
>>>>> However, he came upon a difficulty and that is - *how do you set up an
>>>>> asynchronous timer in C?*
>>>>>
>>>>>  
>>>> It depends what you need that timer for.
>>>>
>>>>
>>>>
>>> The timer is needed to countdown the period between stopping and
>>> restarting the loop. The methods I have tried all halt the playback on a
>>> single frame and the ui also becomes unresponsive while the timer is in
>>> process.
>>>  
>> That sounds like it needs to be be quite accurate, or not?
>>
>>
> 
> It just needs to work ;-)

Are you really sure? :-p


>>> All I would like to do is pass a zero byte to the audio signal handling
>>> code while the timer is in progress. The rest of the interface should
>>> stay active.
>>>  
>> A simple approach might be to just set a counter and have the
>> audio-process count it down (in audio-samples). Once it reaches zero:
>> play again.
>>
>>
> 
> The problem is how to set a counter that doesn't block the rest of the
> app while it is in process.
> 

Outline:

global:
static long int mycounter = 0;

main-thread:
 if (need_to pause) mycounter = time_to_pause * sample_rate;

audio-thread:
 if (mycounter > 0) { mycounter -= samples_processed_here; }
 if (mycounter > 0) mute;
 else play;


The 'mycounter' variable does not need to be global. It can be part of
the track struct or class eg. track->mutecounter.
..and eventually you implement it to be sample-accurate (the above is
just an outline).

Cheers!
robin

-- 
Robin Gareus   mail: ro...@gareus.org
site: http://gareus.org/   chat: xmpp:rgar...@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/

Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Can someone add 2 features to Kluppe?

[Robin Gareus]

On 07/20/2010 09:17 AM, Patrick Shirkey wrote:
> On 07/20/2010 09:45 AM, Robin Gareus wrote:
>> On 07/20/2010 01:06 AM, Louigi Verona wrote:
>>   
>>>
>>> Hey guys!
>>>
>>> Some time ago I have asked someone to look into Kluppe and add a
>>> couple of
>>> features.
>>> My request was not ignored and Patrick Shirkey was kind enough to
>>> volunteer
>>> to try to help.
>>>
>>> However, he came upon a difficulty and that is - *how do you set up an
>>> asynchronous timer in C?*
>>>  
>> It depends what you need that timer for.
>>
>>
> 
> The timer is needed to countdown the period between stopping and
> restarting the loop. The methods I have tried all halt the playback on a
> single frame and the ui also becomes unresponsive while the timer is in
> process.

That sounds like it needs to be be quite accurate, or not?

> All I would like to do is pass a zero byte to the audio signal handling
> code while the timer is in progress. The rest of the interface should
> stay active.

A simple approach might be to just set a counter and have the
audio-process count it down (in audio-samples). Once it reaches zero:
play again.

>> In gtk there's a g_timeout_add(). easy to use.
>> 
> Will check that one. Might do the trick.

Don't forget to read the note:
http://library.gnome.org/devel/glib/unstable/glib-The-Main-Event-Loop.html#g-timeout-add

It's not very accurate but Example code is easy to come by.

>> To writing your own:
>> `apropos pthread` and more specifically `man pthread_create`.
>>
>>
> Otherwise will look into this.
> 
>> usleep() sleeps at least, and select() sleeps at most a certain period
>> of time. http://freej.dyne.org/codedoc/fps_8cpp_source.html line 132ff
>> has examples of both.
>>
> 
> Tried both of these options and they cause the app to pause with an
> annoying buzz while the timer is in effect.

In that case you should get x-runs. Otherwise it may well be that you
simply don't zero the audio-output. It's hard to tell what's going on
w/o seeing the source.

As for the GUI being unresponsive: The key part is to use usleep() in a
separate thread.

Here are two simple examples using pthread to do so:
 http://rg42.org/_media/wiki/async-timer.c  # use a byte to indicate
 http://rg42.org/_media/wiki/async-timer2.c # use a MUTEX

You may want to elaborate on the usleep() call (fi. check for EINTR -
see the freeJ source).

>> For [more] accurate timing: RTC or HPET. Example code comes
>> with the kernel:
>>   linux-2.6/Documentation/rtc.txt
>>   linux-2.6/Documentation/hpet.txt
>>
>> There's a couple of other options fi. if you want to sync
>> hardware-devices using IRQs.. and the jack_process_callback is also very
>> good timer :)
>>
>>
> 
> Not required for this task.
> 
> 
> 
>>> It stopped right there. I was wondering if anyone could help us with
>>> that
>>> matter?
>>>
>>>
>>> Cheers!
>>>
>>>  

ciao
robin

-- 
Robin Gareus   mail: ro...@gareus.org
site: http://gareus.org/   chat: xmpp:rgar...@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/

Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Can someone add 2 features to Kluppe?

[Robin Gareus]

On 07/20/2010 01:06 AM, Louigi Verona wrote:
> 
> 
> Hey guys!
> 
> Some time ago I have asked someone to look into Kluppe and add a couple of
> features.
> My request was not ignored and Patrick Shirkey was kind enough to volunteer
> to try to help.
> 
> However, he came upon a difficulty and that is - *how do you set up an
> asynchronous timer in C?*

It depends what you need that timer for.

In gtk there's a g_timeout_add(). easy to use.

To writing your own:
`apropos pthread` and more specifically `man pthread_create`.

usleep() sleeps at least, and select() sleeps at most a certain period
of time. http://freej.dyne.org/codedoc/fps_8cpp_source.html line 132ff
has examples of both.
For [more] accurate timing: RTC or HPET. Example code comes
with the kernel:
 linux-2.6/Documentation/rtc.txt
 linux-2.6/Documentation/hpet.txt

There's a couple of other options fi. if you want to sync
hardware-devices using IRQs.. and the jack_process_callback is also very
good timer :)

> It stopped right there. I was wondering if anyone could help us with that
> matter?
> 
> 
> Cheers!
> 


-- 
Robin Gareus   mail: ro...@gareus.org
site: http://gareus.org/   chat: xmpp:rgar...@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/

Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Tests directly routing pc's midi-in to midi-out

[Robin Gareus]

On 07/16/2010 11:46 AM, Arnold Krille wrote:
> On Friday 16 July 2010 09:50:39 Ralf Mardorf wrote:
>> On Thu, 2010-07-15 at 09:56 +0200, Arnold Krille wrote:
>>> You really should do that test first before speculating about the outcome
>>> and your audience.
>> Btw. I tested my own music.
>> First I played inside songs from other people a Ralf-mastering of my own
>> music.
>> Most people didn't like my song.
>> Some weeks later I played the same song inside other songs from other
>> people by a loudness-war-mastering.
>> Most people liked the song.
>> Playing the same song two times can't be called heavy rotation, hence
>> they were not accustomed to my song, but they need a bad mastering to be
>> fine with this song.
>> A blind study is useless regarding to musical issues.
> 
> Apples and oranges.

Since LAC2010 the bitten fruit is a banned word. You mean bananas &
oranges, don't you?

> You are working on midi-latency-jitter. Which is measurable. And the test is 
> when the jitter becomes unbearable.
> 
> Taste on the other thing is not measurable and while you could quantify it, 
> common sense says that taste-minorities are valuable too...
> 
>> Or do you think we should start mixing music optimised to loudness,
>> because tests show that the audience prefers music without dynamic?
> 
> Taste-minorities. You play your dynamic-rich songs to fans of classical music 
> and see their reactions. If you can distinguish the "like it because of 
> dynamics" from the "don't like it because of rock-vs-classical". Which just 
> shows that taste is not measurable.
> 
> And no, pop industry doesn't measure taste, it just measures profit.

LOL.

> Have fun,
> 
> Arnold

We're getting seriously off-topic here. After all, this is developer
list. What happened to the ALSA MIDI Jitter measurements and test-samples?

robin






___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Tests directly routing pc's midi-in to midi-out

[Robin Gareus]

On 07/15/2010 02:45 PM, Ralf Mardorf wrote:
> On Thu, 2010-07-15 at 13:45 +0200, Robin Gareus wrote:
>> On 07/15/2010 01:07 PM, Ralf Mardorf wrote:
>>> On Thu, 2010-07-15 at 12:55 +0200, Clemens Ladisch wrote:
>>>> Ralf Mardorf wrote:
>>>>> - instead of dev.hpet.max-user-freq=64 I'll try 1024 or 2048 as Robin
>>>>> mentioned
>>>>
>>>> This parameter will not have any effect on anything because there is no
>>>> program that uses the HPET timers from userspace. 
>>
>> That'd be correct if Ralf would stick to 'amidiplay' and friends for his
>> tests.
> 
> While at least one friend throw his Apple MacOs through the window. I'm
> not kidding. Modern computers + music + my friends = not good. I've got
> two kinds of friends, the once who say I shouldn't use a modern computer
> and the others who say, I should buy Nuendo and expensive hardware. And
> btw. I don't have got 1000 friends, but just a handful.
> If I would ask my neighbours to listen, they would be fine with bad
> timing, regarding to their habits, listening to the radio at prime time.

Took me a while to catch that drift. I meant friends of 'amidiplay'
(eg 'amidirecord', 'aseqdump', etc) with the aim to keep things simple
for testing.

"..and friends" is an English idiom; sorry to put you off track.

> Anyway, I could ask people to listen, but I'm sure this would be
> useless.
> 
>> There are a couple of audio-tools who can use either RTC or HPET for
>> timing, although most of them need an option to explicitly enable it.
>>
>>>> When high-resolution
>>>> timers are used by ALSA, this is done inside the kernel where there is
>>>> no limit on the maximum frequency.
>>
>> Thanks for that explanation. It makes perfect sense.
>> I take it the same must be true for dev.rtc.max-user-freq as well.
>>
>> BTW. Do you know the unit of these values?
>>   cat /sys/class/rtc/rtc0/max_user_freq
>>   cat /proc/sys/dev/hpet/max-user-freq
>> are they Hz?
>>
>> linux-2.6/Documentation/hpet.txt does not mention it at all and
>> linux-2.6/Documentation/rtc.txt hints it's Hz but does not explicitly
>> say so.
>>
>>>> Regards,
>>>> Clemens
>>>
>>> IIRC someone on jack-devel mailing list had issues when using mplayer
>>> with the value 64 and it was solved when using the value 1024. But as I
>>> mentioned before, for my USB MIDI there was a difference between system
>>> timer and hr timer, but there was no difference for the value 64 and
>>> 1024, when using hr timer.
>>>
>>> Btw. I don't understand what a maximum frequency in the context does
>>> mean. If 64 or 1024 should have impact, what would be the result?
>>>
>>> System timer for a kernel-rt is set up to 1000Hz and hr timer is at
>>> 10Hz.
>>>
>>> What is 'max-user-freq' for?
>>
>> It limits the maximum frequency at which user-space applications can
>> [request to] receive "wakeup calls" from the hr-timer.
>>
>> see also the "Timers" thread on LAD last November:
>> http://linuxaudio.org/mailarchive/lad/2009/11/7/161647
> 
> Okay, what ever user-space might be, 

It's the opposite of "kernel-space" :)
http://en.wikipedia.org/wiki/User_space

> I assume regarding to the
> explanations it's unimportant for rt. And as mentioned by the text of
> the link, I can confirm that at least my USB MIDI is better when using
> hr timer.
> 
> I'll test amidiplay, but again, playing all MIDI instruments at the same
> isn't the major problem, perhaps just for me, resp. for people with
> 'golden ears'.

Lets try something very simple:

ONE)
- Take a very simple midi-file.
- Use 'aplaymidi' to send it from your PC to your external midi-drum
machine. - Use your drum-synth's "klick" or "woodblock" sound or sth
very dry with a good attack.
- do a quick ear-test if you can hear midi-jitter?
- capture the audio-output of the external-midi-synth with arecord.

Rewind and do it again.
Post the two files and the used .mid on a web-server or some drop-box.

If you want to check yourself: Align the first-beat of the captured
audio files in a multi-track audio-editor. While it will involve a bit
of manual labor to quantify the jitter. It'll at least be solid evidence.


TWO)
- launch an external MIDI-metronome (eg your Atari ST)
- connect it to your PC
- use 'arecordmidi' to generate a .mid file from it.

Repeat at least once and post the tw

Re: [LAD] Tests directly routing pc's midi-in to midi-out

[Robin Gareus]

On 07/15/2010 01:07 PM, Ralf Mardorf wrote:
> On Thu, 2010-07-15 at 12:55 +0200, Clemens Ladisch wrote:
>> Ralf Mardorf wrote:
>>> - instead of dev.hpet.max-user-freq=64 I'll try 1024 or 2048 as Robin
>>> mentioned
>>
>> This parameter will not have any effect on anything because there is no
>> program that uses the HPET timers from userspace. 

That'd be correct if Ralf would stick to 'amidiplay' and friends for his
tests.

There are a couple of audio-tools who can use either RTC or HPET for
timing, although most of them need an option to explicitly enable it.

>> When high-resolution
>> timers are used by ALSA, this is done inside the kernel where there is
>> no limit on the maximum frequency.

Thanks for that explanation. It makes perfect sense.
I take it the same must be true for dev.rtc.max-user-freq as well.

BTW. Do you know the unit of these values?
  cat /sys/class/rtc/rtc0/max_user_freq
  cat /proc/sys/dev/hpet/max-user-freq
are they Hz?

linux-2.6/Documentation/hpet.txt does not mention it at all and
linux-2.6/Documentation/rtc.txt hints it's Hz but does not explicitly
say so.

>> Regards,
>> Clemens
> 
> IIRC someone on jack-devel mailing list had issues when using mplayer
> with the value 64 and it was solved when using the value 1024. But as I
> mentioned before, for my USB MIDI there was a difference between system
> timer and hr timer, but there was no difference for the value 64 and
> 1024, when using hr timer.
> 
> Btw. I don't understand what a maximum frequency in the context does
> mean. If 64 or 1024 should have impact, what would be the result?
> 
> System timer for a kernel-rt is set up to 1000Hz and hr timer is at
> 10Hz.
> 
> What is 'max-user-freq' for?

It limits the maximum frequency at which user-space applications can
[request to] receive "wakeup calls" from the hr-timer.

see also the "Timers" thread on LAD last November:
http://linuxaudio.org/mailarchive/lad/2009/11/7/161647

> Cheers!
> 
> Ralf
> 
> 
best,
robin

-- 
Robin Gareus   mail: ro...@gareus.org
site: http://gareus.org/   chat: xmpp:rgar...@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/

Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] ALSA MIDI latency test results are far away from reality

[Robin Gareus]

On 07/14/2010 03:23 PM, Ralf Mardorf wrote:

[..]
> $ su -c "chgrp audio /dev/hpet"
Its also writable for the group, right?

> $ su -c "sysctl -w dev.hpet.max-user-freq=64"

Documentation on this value is hard to come by, but I think it's unit is
Hz. So you'll want
  su -c "sysctl -w dev.hpet.max-user-freq=1024"
or even more :)

try:
echo 2048 | sudo tee /sys/class/rtc/rtc0/max_user_freq
echo 2048 | sudo tee /proc/sys/dev/hpet/max-user-freq

[..]
ciao,
robin


-- 
Robin Gareus   mail: ro...@gareus.org
site: http://gareus.org/   chat: xmpp:rgar...@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/

Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] ALSA MIDI latency test results are far away from reality

[Robin Gareus]

On 07/14/2010 07:58 PM, Ralf Mardorf wrote:
> On Wed, 2010-07-14 at 17:30 +0200, Robin Gareus wrote:
>> On 07/14/2010 04:22 PM, Ralf Mardorf wrote:
>>> Hi Robin :)
>>>
>>> On Wed, 2010-07-14 at 15:44 +0200, Robin Gareus wrote:
>>>> On 07/14/2010 03:23 PM, Ralf Mardorf wrote:
>>>>> [..]
>>>>> AND IT'S AUDIBLE THAT THERE IS MUCH MORE JITTER BUT 1.1 ms.
>>>>>
>>>>> Any hints how to solve this are welcome.
>>>>
>>>> Did you try to start jackd with -p64 instead of -p1024
>>>
>>> A good argument, because when I made tests in the past for the USB MIDI,
>>> things become better at  >= -p256 (when I had this Windows test install
>>> latency for the EWX 24/96 audio was less high than for Linux). The
>>> problem here is, that I need at least -p512 and even than I'm not safe
>>> regarding to issues for JACK audio, that's why I used -p1024 instead of
>>> -p512. For a test -p64 should work, but when recording music I would
>>> need to increase it step by step until a minimum of -p512.
>>
>> I'm sorry; don't understand that. Are you getting [audio] x-runs or what
>> is the problem using -p64 (or even -p32)?
> 
> Yes there are lapse, even if there should be no messages about xruns.
> 
>> I was hinting that the audible midi-jitter could be a result of
>> midi-messages getting 'quantizied' to jack-periods.
> 
> It seems to be like that. Take a look at my email with the 
>subject: 
> Correlation of alsa -p value and hw
> MIDI jitter
> 
>> A JACK-MIDI app which does not honor 'jack_midi_event_t->time' but
>> simply processes all queued midi-events on each jack_process_callback()
>> will result in the symptoms you describe (snare & kick on the same
>> beat). One example of such an app is "a2j".

It turned out I was using an ancient version of "a2j".

> I did use Qtractor, but had the same issue when using Rosegarden a long
> time ago. But we are talking about ALSA MIDI to the hardware
> MIDInterface?!
Originally i was only talking about JACK-MIDI apps.

>>> IIRC when I did tests for the USB MIDI with -p64 or even -p125 (I'm not
>>> sure) it theoretically did work, but this isn't a solution, because at
>>> some point JACK audio will fail.
>>
>> How does it fail? x-runs?
> 
> All kinds of dropouts, even the left and right channel seem to get out
> of phase. Just running FluidSynth DSSI playing a kick and a rim-shot was
> without audible failure at -p16, but I'm sure I won't be able to do
> multi-trach recording with -p16.
> 
>>
>> JACKd works quite robust here with the UA25 and FA101 at 64fpp.
>>
>>>> using JACK-midi, I've encountered a similar issue with fluidsynth always
>>>> synchronizing note-start/ends to jack cycles.
>>>>
>>>> Simply lowering the frames-per-period got me playing again so I did not
>>>> check if it's related to JACK-midi or FluidSynth 1.1.1 in general.
>>>
>>> At least FluidSynth DSSI (host is Qtractor) is able to play in unison
>>> with any DSSI or virtual ALSA MIDI and JACK MIDI (-Xseq) synth on my
>>> machine. Just 'in unison' for virtual synth to hw synth there sometimes
>>> is more delay, but just an early reflection like effect.
>>>
>>> Note! It was hard to groove when I connected the master keyboard to ALSA
>>> hw MIDI in --> DIRECTLY TO --> ALSA hw MIDI out and this to a 100% ok
>>> drum module. Directly connecting the master keyboard to the drum module
>>> there were no issues.
>>
>> Aha, by this we can infer that your problem is ALSA or kernel/timing
>> related.
>>
>> To verify this, take everything up from there (eg. qtractor, fluidsynth)
>> out of the picture for now.
>>
>> 1) Use 'amidiplay' to send a some midi-song directly to your
>> drum-module. -> Is there still audible jitter?
> 
> On a todo list, but there seems to be a correlation to JACK audio.

The idea is to remove all correlations. Otherwise it's very hard to find
the problem.

It looks like you're chasing [at least] two different issues:

1) ALSA / hardware jitter

2) qtractor/fluidsynth timing/sync


Don't even start JACKd. just use 'aplaymidi'.
or 'ametro' http://perso.wanadoo.es/plcl/ametro/ametro-en.html

>> 2) Do you have a Hardware MIDI Sequencer? Have it play a simple
>> metronome beat and dump incoming MIDI-messages. See if the timestamps of
>> 

Re: [LAD] ALSA MIDI latency test results are far away from reality

[Robin Gareus]

On 07/14/2010 06:31 PM, Nedko Arnaudov wrote:
> Robin Gareus  writes:
> 
>> I was hinting that the audible midi-jitter could be a result of
>> midi-messages getting 'quantizied' to jack-periods.
>>
>> A JACK-MIDI app which does not honor 'jack_midi_event_t->time' but
>> simply processes all queued midi-events on each jack_process_callback()
>> will result in the symptoms you describe (snare & kick on the same
>> beat). One example of such an app is "a2j".
> 
> What version? 

release-4 - the latest on svn://svn.gna.org/svn/a2jmidid

> I can clearly see code that handles this in the current
> version. It is in jack.c, a2j_alsa_output_thread(), lines 385-411

I've just seen that there's git://repo.or.cz/a2jmidid.git and jumped
from release-4 to release-6.

ciao,
robin


-- 
Robin Gareus   mail: ro...@gareus.org
site: http://gareus.org/   chat: xmpp:rgar...@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/

Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] ALSA MIDI latency test results are far away from reality

[Robin Gareus]

On 07/14/2010 05:27 PM, Ralf Mardorf wrote:
> On Wed, 2010-07-14 at 17:24 +0200, Ralf Mardorf wrote:
>> On Wed, 2010-07-14 at 17:21 +0200, Ralf Mardorf wrote:
>>> On Wed, 2010-07-14 at 10:53 -0400, Paul Davis wrote:
 On Wed, Jul 14, 2010 at 9:52 AM, Clemens Ladisch  
 wrote:
> Is this connection through JACK or through ALSA, i.e., does it show up
> in the output of "aconnect -l"?  From what I understand, JACK's sample-
> synchronous timing always adds latency, and might add period-related
> jitter depending on the implementation.

 the good stuff adds 1 JACK period of latency to whatever the ALSA
> 
> PPS:
> 
> A misunderstanding by me?
> 
 sequencer's direct delivery + the driver does, and zero jitter.
> 
> Is there JACK MIDI for hw MIDI too, but only for virtual synth?

No, JACK-MIDI is a protocol in software.

There are bridges to hardware which go connect either via ALSA-sequencer
or raw-ALSA interface to the MIDI hardware.

JACKd itself includes those bridges (-Xseq, -Rraw) and there are also
stand-alone apps (fi a2jmidi_bridge, a2jmidid,..) which can do the same.

> - Ralf
> 
> *Offline now*
> 
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] ALSA MIDI latency test results are far away from reality

[Robin Gareus]

On 07/14/2010 04:22 PM, Ralf Mardorf wrote:
> Hi Robin :)
> 
> On Wed, 2010-07-14 at 15:44 +0200, Robin Gareus wrote:
>> On 07/14/2010 03:23 PM, Ralf Mardorf wrote:
>>> [..]
>>> AND IT'S AUDIBLE THAT THERE IS MUCH MORE JITTER BUT 1.1 ms.
>>>
>>> Any hints how to solve this are welcome.
>>
>> Did you try to start jackd with -p64 instead of -p1024
> 
> A good argument, because when I made tests in the past for the USB MIDI,
> things become better at  >= -p256 (when I had this Windows test install
> latency for the EWX 24/96 audio was less high than for Linux). The
> problem here is, that I need at least -p512 and even than I'm not safe
> regarding to issues for JACK audio, that's why I used -p1024 instead of
> -p512. For a test -p64 should work, but when recording music I would
> need to increase it step by step until a minimum of -p512.

I'm sorry; don't understand that. Are you getting [audio] x-runs or what
is the problem using -p64 (or even -p32)?

I was hinting that the audible midi-jitter could be a result of
midi-messages getting 'quantizied' to jack-periods.

A JACK-MIDI app which does not honor 'jack_midi_event_t->time' but
simply processes all queued midi-events on each jack_process_callback()
will result in the symptoms you describe (snare & kick on the same
beat). One example of such an app is "a2j".

> IIRC when I did tests for the USB MIDI with -p64 or even -p125 (I'm not
> sure) it theoretically did work, but this isn't a solution, because at
> some point JACK audio will fail.

How does it fail? x-runs?

JACKd works quite robust here with the UA25 and FA101 at 64fpp.

>> using JACK-midi, I've encountered a similar issue with fluidsynth always
>> synchronizing note-start/ends to jack cycles.
>>
>> Simply lowering the frames-per-period got me playing again so I did not
>> check if it's related to JACK-midi or FluidSynth 1.1.1 in general.
> 
> At least FluidSynth DSSI (host is Qtractor) is able to play in unison
> with any DSSI or virtual ALSA MIDI and JACK MIDI (-Xseq) synth on my
> machine. Just 'in unison' for virtual synth to hw synth there sometimes
> is more delay, but just an early reflection like effect.
>
> Note! It was hard to groove when I connected the master keyboard to ALSA
> hw MIDI in --> DIRECTLY TO --> ALSA hw MIDI out and this to a 100% ok
> drum module. Directly connecting the master keyboard to the drum module
> there were no issues.

Aha, by this we can infer that your problem is ALSA or kernel/timing
related.

To verify this, take everything up from there (eg. qtractor, fluidsynth)
out of the picture for now.

1) Use 'amidiplay' to send a some midi-song directly to your
drum-module. -> Is there still audible jitter?

2) Do you have a Hardware MIDI Sequencer? Have it play a simple
metronome beat and dump incoming MIDI-messages. See if the timestamps of
each midi-note-on message are identically spaced.

'aseqdump' (at least version 1.0.22 which I currently use) does not
print timing-info, 'kmidimon' does.

> I need to do something else now, but I take time off. From Friday
> (perhaps earlier) until next Sunday noon I could spend the whole days
> for this MIDI issue only.
> 
> Resume:
> 
> I assume that -p64 would solve this 'looong early reflection like
> effect/async', but then hard disk recording will become impossible.
> 
> The target is, that Linux at least replace the Atari ST as sequencer +
> an analog 4-Track machine synced by SMPTE. With -p64 4-track recoding
> would become impossible.

I'm pretty sure that you can get a stable 64fpp setup, but one thing at
a time. let's keep this thread to MIDI just now.

> 'Read you later' today or at the latest on Friday.

enjoy a good long week-end.

> Cheers!
> 
> Ralf

ciao,
robin

-- 
Robin Gareus   mail: ro...@gareus.org
site: http://gareus.org/   chat: xmpp:rgar...@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/

Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] ALSA MIDI latency test results are far away from reality

[Robin Gareus]

On 07/14/2010 03:23 PM, Ralf Mardorf wrote:
> [..]
> AND IT'S AUDIBLE THAT THERE IS MUCH MORE JITTER BUT 1.1 ms.
> 
> Any hints how to solve this are welcome.

Did you try to start jackd with -p64 instead of -p1024

using JACK-midi, I've encountered a similar issue with fluidsynth always
synchronizing note-start/ends to jack cycles.

Simply lowering the frames-per-period got me playing again so I did not
check if it's related to JACK-midi or FluidSynth 1.1.1 in general.

ciao,
robin

-- 
Robin Gareus   mail: ro...@gareus.org
site: http://gareus.org/   chat: xmpp:rgar...@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/

Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] PCI MIDI jitter - comparison Ubuntu (bad) and Suse (might be ok)

[Robin Gareus]

On 07/11/2010 05:18 PM, Ralf Mardorf wrote:
> Hi Robin :)
> 
> On Sun, 2010-07-11 at 17:11 +0200, Robin Gareus wrote:
>> Hi Ralf,
>>
>> You are comparing a banana and an orange to find out which one is
>> sweeter. Given the nature of the problem it would help a lot to have as
>> little differences between the systems under test, otherwise it's
>> impossible to track it down.
>>
>> I hazard a guess that it's Ubuntu's 2.6.32 realtime-preemt-kernel.
>> There are no official 2.6.32 rt-patches and it's likely that some of the
>> back/forward ports have screwed things up.
> 
> Good argument! OTOH an audio distro shouldn't use a kernel that will
> increase latency. I'll build 2.6.31.6-rt19 for Ubuntu Studio, btw. I had
> this kernel for 64 Studio too, but only in combination with USB MIDI.
> 
>> Is 'cat /proc/interrupts' identical on both systems?
>> what about 'ps ax | wc -l' and
>> 'ps -eo pid,class,rtprio,ni,pri,pcpu,stat,comm --sort -rtprio'
>> Are there high-priority jobs present on Ubuntu which are not on SuSE?
> 
> I dunno, I'll run those commands and post them later, building a kernel
> will take some time.

The whole output of 'ps -eo...' will be tooo long. Just have a look
and check for high priority processes that are different on both systems.
If you have rtirq installed: '/etc/init.d/rtirq status' will show the
same list but only display processes with RTPRIO set.

Oh and I missed that the Ubuntu's 2.6.32.XX is actually not a rt-preemt
kernel. many thanks to Arnout to spot that.

If there's still a difference between SuSe & Ubuntu using the identical
kernel, with no significant high-priority processes: please post the
version of the alsa-libs for both systems.

Not sure if it has been mentioned before, but you should set your
soundcard's IRQ handler priority to sth "high" (eg 90) and use '-P 89'
with alsa-midi-latency-test.
With the default of "-P 99" the kernel will always end up inverting
priorities to run it (the overhead for doing so is low but it may still
be relevant).


Thanks for being persistent on the Midi Jitter issue. Some of that info
is bound to come in handy..

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] PCI MIDI jitter - comparison Ubuntu (bad) and Suse (might be ok)

[Robin Gareus]

Hi Ralf,

You are comparing a banana and an orange to find out which one is
sweeter. Given the nature of the problem it would help a lot to have as
little differences between the systems under test, otherwise it's
impossible to track it down.

I hazard a guess that it's Ubuntu's 2.6.32 realtime-preemt-kernel.
There are no official 2.6.32 rt-patches and it's likely that some of the
back/forward ports have screwed things up.

Is 'cat /proc/interrupts' identical on both systems?
what about 'ps ax | wc -l' and
'ps -eo pid,class,rtprio,ni,pri,pcpu,stat,comm --sort -rtprio'
Are there high-priority jobs present on Ubuntu which are not on SuSE?

What happens if you use the same kernel (SuSE's kernel on Ubuntu, or
vice versa) but different disto user-lands?  Is there still a difference
in your measurements?

ciao,
robin

On 07/11/2010 04:53 PM, Ralf Mardorf wrote:
> Hi :)
> 
> today I compared a default Ubuntu Studio with and without the
> proprietary NVIDIA driver. Note that for Ubuntu Studio 2 tests failed
> because of time out errors, but even the tests that were passed with
> success are significantly less good, than the tests with openSUSE, were
> I set up audio myself.
> Ubuntu based Linux until now were my music Linux, e.g 64 Studio 3.0 and
> 3.3, but I wonder if bad MIDI latency is depending to Ubuntu.
> For Ubuntu Studio even PCI MIDI has got more jitter, but USB MIDI for
> Suse, see older test in the archives.
> 
> What might be the difference between Ubuntu and Suse?
> 
> Could anybody compare different distros too?
> 
> 
> Ubuntu Studio 10.04 amd64
> 2 x Terratec EWX 24/96 (2 single cards, but 1 virtual card)
> Frequency scaling ?
> 
> 
> spinymo...@ubuntu:~$ hwinfo --gfxcard
>   Driver: "nouveau"
>   Driver Modules: "drm"
>   IRQ: 18
> spinymo...@ubuntu:~$ alsa-midi-latency-test -l
>  PortClient name  Port name
>  14:0Midi Through Midi Through Port-0
>  16:0TerraTec EWX24/96TerraTec EWX24/96 MIDI
>  20:0TerraTec EWX24/96TerraTec EWX24/96 MIDI
> 128:0TiMidity TiMidity port 0
> 128:1TiMidity TiMidity port 1
> 128:2TiMidity TiMidity port 2
> 128:3TiMidity TiMidity port 3
> spinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o20:0 -i20:0
>> alsa-midi-latency-test 0.0.3
>> set_realtime_priority(SCHED_FIFO, 99).. done.
>> clock resolution: 0.1 s
>> SUCCESS
> 
>  best latency was 1.00 ms
>  worst latency was 1.97 ms, which is great.
> 
> spinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o20:0 -i20:0
>> alsa-midi-latency-test 0.0.3
>> set_realtime_priority(SCHED_FIFO, 99).. done.
>> clock resolution: 0.1 s
>> SUCCESS
> 
>  best latency was 1.00 ms
>  worst latency was 3.36 ms, which is great.
> 
> spinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0
>> alsa-midi-latency-test 0.0.3
>> set_realtime_priority(SCHED_FIFO, 99).. done.
>> clock resolution: 0.1 s
>> SUCCESS
> 
>  best latency was 0.99 ms
>  worst latency was 1.93 ms, which is great.
> 
> spinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0
>> alsa-midi-latency-test 0.0.3
>> set_realtime_priority(SCHED_FIFO, 99).. done.
>> clock resolution: 0.1 s
>> SUCCESS
> 
>  best latency was 0.99 ms
>  worst latency was 1.74 ms, which is great.
> 
> spinymo...@ubuntu:~$ uname -a
> Linux ubuntu 2.6.32-23-preempt #37-Ubuntu SMP PREEMPT Fri Jun 11
> 10:19:07 UTC 2010 x86_64 GNU/Linux
> spinymo...@ubuntu:~$ envy24control
> 0xcf00, irq 20, Master Clock int 44100
> 
> No envy24control for
> 0xcb00, irq 21, Master Clock ?
> 
> 20:0 opto S/PDIF out --> 16:00 opto S/PDIF in
> 
> 
> Ubuntu Studio 10.04 amd64
> 2 x Terratec EWX 24/96 (2 single cards, but 1 virtual card)
> Frequency scaling ?
> 
> 
> spinymo...@ubuntu:~$ hwinfo --gfxcard
>   Driver: "nvidia"
>   Driver Modules: "nvidia"
>   IRQ: 18
> spinymo...@ubuntu:~$ alsa-midi-latency-test -l
>  PortClient name  Port name
>  14:0Midi Through Midi Through Port-0
>  16:0TerraTec EWX24/96TerraTec EWX24/96 MIDI
>  20:0TerraTec EWX24/96TerraTec EWX24/96 MIDI
> 128:0TiMidity TiMidity port 0
> 128:1TiMidity TiMidity port 1
> 128:2TiMidity TiMidity port 2
> 128:3TiMidity TiMidity port 3
> pinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o20:0 -i20:0
>> alsa-midi-latency-test 0.0.3
>> set_realtime_priority(SCHED_FIFO, 99).. done.
>> clock resolution: 0.1 s
>> SUCCESS
> 
>  best latency was

Re: [oauth] liboauth and LinkedIn: Getting a 404 error

[Robin Gareus]

On 06/21/2010 09:42 PM, Grant wrote:
> Right now I am trying to get liboauth working with LinkedIn, but I
> can't even get a request token. I've read the LinkedIn documentation,
> and changed my code around quite a bit testing different methods.
> 
> Here is my code:
> http://pastie.org/private/tiaog08s8o7521qoas2u5w
> 
> I just converted one of the C examples to C++ and changed it around.
> I can't seem to figure out what the problem is, has anyone else used
> liboauth with LinkedIn?
> Maybe someone can notice something I'm not seeing...
> 
You are missing the terminating "\r\n" for the HTTP header.

line 101 in your code should read:
 header += ("oauth_version=\"" + params["oauth_version"] + "\"\r\n");

HTH,
robin

PS. is your date wrong? I only received this message now:
Received: by 3g2000vbg.googlegroups.com with HTTP; Mon, 28 Jun 2010
09:57:20 -0700 (PDT) but the message dates back a week. weird.

-- 
Robin Gareus   mail: ro...@gareus.org
site: http://gareus.org/   chat: xmpp:rgar...@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/

Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42

-- 
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oa...@googlegroups.com.
To unsubscribe from this group, send email to 
oauth+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/oauth?hl=en.

Re: [LAD] Jack latency handling (Re: Software for recording digital audio?)

[Robin Gareus]

On 06/25/2010 01:23 PM, Kjetil S. Matheussen wrote:
> 
> Robin Gareus:
>> >
>> > 0.49 has this feature implemented. Use the "-jt" option.
>> >
>> > It should be sample sync,
>>
>> Almost. It does not yet compensate for port-latency. It is important for
>> both effects that introduce latency as well as to keep physical I/O in
>> sync with apps.
>>
>> see jack_port_get_latency() and jack_port_get_total_latency()
>> at http://jackaudio.org/files/docs/html/group__PortFunctions.html
>>
> 
> Thanks for the info! I also wonder, does jack compansate for
> latency when it mixes the outputs from ports (i.e. when several
> output ports are connected to a jack_capture port), so that
> the sound is in sync?

Jack2 (aka jack 1.9.6 SVN r4008) adds and sets the port-latencies of
connected [upstream] ports accordingly. The application itself is then
responsible for compensating accordingly.


Here's an example:

The "system_playback" port has a latency of 1024 frames and so is the
jack_buffersize (frames per period). "app1" is a simple jack application
that prints the _total_-port-latency of it's in & out ports every time
they change and announces a latency of 512 frames on its input port (The
individual port-latencies themselves can be displayed with `lack_lsp -l`).

Unconnected "app1" prints a total out-port latency of 0 and the in-port
latency which was configured when creating the port: 512.

Now:

app1 ---> play #  app1: out-port latency:1024
  app1 #  app1: in-port  latency: 512
-=-=-=-

app1 -play #  app1: out-port latency: 512
  \-> app1 #  app1: in-port  latency: 512

-=-=-=-

app1 -+-> play #  app1: out-port latency: 1024
  \-> app1 #  app1: in-port  latency: 1536


Note that the scenario is different if the client announces 512 frames
latency on it's output port _instead_ of its input:

Unconnected "app2" prints an out-port latency of 512 and the in-port:0

app2 ---> play #  app2: out-port latency:1536
  app2 #  app2: in-port  latency:   0
-=-=-=-

app2 -play #  app2: out-port latency: 512
  \-> app2 #  app2: in-port  latency: 512

-=-=-=-

app2 -+-> play #  app2: out-port latency: 1536
  \-> app2 #  app2: in-port  latency: 1536


If you want to test with jack1:
   http://rg42.org/_media/wiki/jtest.c
(NB. the test-app only announces an internal latency, it actually has
none. I'll throw in a buffer on the next cold rainy day.)



Anyway: Is there a simple LADSPA or LV2 host that sets port-latencies
correctly? Well, not many plugins announce their latency but neither
jack-rack nor lv2_jack_host set that value to to the jack-ports;
ardour does (fi. test w/ the multiband EQ 1197 from Steve Harris).
Check with `jack_lsp -l` or better: listen to it by adding a
phase-inverter into a bus and see if you can cancel the signals.

ciao,
robin

-- 
Robin Gareus   mail: ro...@gareus.org
site: http://gareus.org/   chat: xmpp:rgar...@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/

Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [oauth] Compiler Error on Mac OSX 10.6.3

[Robin Gareus]

On 06/02/2010 06:40 PM, Robin Gareus wrote:
> Hi Heath,
> 
> Let's take this off-mailing-list; we're facing some compiler/linker
> issues which is beyond OAuth discussion. Let's report back there when
> we're done, shall we?

All right, for all those facing the same issue: linking an app
statically on Darwin/OSX with liboauth and dependencies, Heath & me came
up with a shell script that walks through the whole process:

http://rg42.org/oss/oauth/osx-static

Cheers!
robin

-- 
Robin Gareus   mail: ro...@gareus.org
site: http://gareus.org/   chat: xmpp:rgar...@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/

Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42

-- 
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oa...@googlegroups.com.
To unsubscribe from this group, send email to 
oauth+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/oauth?hl=en.

Re: [LAD] Software for recording digital audio?

[Robin Gareus]

On 06/24/2010 02:55 PM, Kjetil S. Matheussen wrote:
> 
> 
> On Wed, 23 Jun 2010, Kjetil S. Matheussen wrote:
> 
>>
>> Andrew C:
>>>
>>> Wow, thanks for the replies guys!
>>>
>>> Of the software mentioned here, my biggest wish is for syncability
>>> with JACK
>>> transport, so I can send the output of one of the linuxsampler
>>> instruments
>>> to the recording software, hit the play button from inside Rosegarden
>>> and
>>> have a perfectly synced audio copy of one particular instrument
>>> output which
>>> I can then drop back into the sequencer timeline and continue with
>>> another
>>> section of the song, thereby freeing up system resources.
>>>
>>> Of course, this rules out jack_capture I'm afraid!
>>>
>>
>> Sorry, I got this feature request about 4 years ago, but haven't
>> implemented it. It should only be about 10-20 extra lines of
>> code. I'll do it very soon.
>>
> 
> 0.49 has this feature implemented. Use the "-jt" option.
> 
> It should be sample sync,

Almost. It does not yet compensate for port-latency. It is important for
both effects that introduce latency as well as to keep physical I/O in
sync with apps.

see jack_port_get_latency() and jack_port_get_total_latency()
at http://jackaudio.org/files/docs/html/group__PortFunctions.html

> but I'm not sure whether the last
> block (the one that received a stop message from jack transport)
> should be recorded? For now it's recorded. If that's wrong,
> I'll fix it in the next release.

While it's safe to just record it, i don't think it should be.
http://jackaudio.org/files/docs/html/group__TransportControl.html reads:

jack_transport_stop() [..] takes effect on the _next_ process cycle.

jack_transport_query() [..] If called from the process thread, pos
corresponds to the first frame of the _current_ cycle and the state
returned is valid for the entire cycle.

IOW: As soon as the app sees a stopped transport in the process loop it
is exactly at, or already a bit later than the actual end.

..but.. you may still need to run a bit further to compensate for
port-latencies.

Cheers!
robin

-- 
Robin Gareus   mail: ro...@gareus.org
site: http://gareus.org/   chat: xmpp:rgar...@ik.nu
blog: http://rg42.org/ lab : http://citu.fr/

Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Testing... There is a problem with the list?

[Robin Gareus]

Marc,

Could you shed some light on this? The server's been up & running
without any issues. And the mail-queue looks "normal".

@Natanael: Did you get a "warning message"? (maybe in your SPAM folder)
If there's repeated bounces from your email address your subscription
would be disabled (you won't be unsubscribed but the message delivery
option in your account preferences for all linuxaudio.org lists would be
set to "false"). Given that you use a gmail account this is however
unlikely...

robin

On 06/21/2010 04:08 PM, Natanael Olaiz wrote:
> Is there any problem with the list(s) server(s)? The last message that I
> received is from friday, but I see in the archive web page that there
> was more since that day.
> 
> The same seems to happens in LAU.
> 
> Natanael.
> 
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Real-time plotting of audio/ oscilloscope.

[Robin Gareus]

On 06/18/2010 02:05 AM, Jeremy wrote:
[..]
> Anyway, is there any library that provides me with an array to write to, and
> it handles refreshing the screen?  That way I would essentially just be
> writing to an array, which should be really fast inside the realtime loop.
>  I thought that is what SDL does, but I guess not.
> 
> Jeremy

Not sure where this is going. You started by saying you only needed a
simple debug tool.. but of course it's fun to tinker with SDL. :)

For drawing array-data on screen, pure-data would be a good choice.
Should not take more than 1 min: just open the Pd help for "tabwrite~"
and replace the "phasor~" with "adc~" to feed it with real-time audio-data.

If you want to stick with SDL, use a jack-ringbuffer (which is basically
an array); the jack-process callback writes into it
and in the main SDL thread: you read from the ring-buffer, plot it,
sleep for 40ms, repeat.

http://das.nasophon.de/jack_oscrolloscope/ is using SDL.

UTSL,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] piano sound fonts

[Robin Gareus]

On 06/17/2010 04:41 PM, Simon Burton wrote:
> 
> Hi all,
> 
> So I'm banging around some piano samples:
> 
> http://pythonicle.net/sounds/output-7.ogg
> http://pythonicle.net/sounds/output-7.mp3
> 
> using phasing (a la Steve Reich) and some piano samples I found here:
> 
> http://www.pianosounds.com/freesoundfont.htm
> 
> Does anyone have a recommendation for a more comprehensive (non-free even)
> piano sound palette ?

maybe the "Salamander"?! It announced on LAU a few weeks back:
http://linuxaudio.org/mailarchive/lau/2010/5/17/168952

http://download.linuxaudio.org/torrents/SalamanderGrandPiano.tar.bz2.torrent
  or direct:
http://download.linuxaudio.org/lau/SalamanderGrandPiano.tar.bz2


> I use python code* and was very happy to be able to import soundfont files.
> 
> I see also these gigasampler files, maybe i can use libgig to access those (?)
> 
> *Here are all my secrets: http://pythonicle.net/svn/projects/dsptools
> Take a look if you are curious. There is python wrappers for using numpy
> with ladspa and portaudio. And i forget what else. One of these days
> I might get around to cleaning all this up, but right now I need to 
> make sounds just to bring some sanity into my world.
> 
> bye for now,
> 
> Simon.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Real-time plotting of audio/ oscilloscope.

[Robin Gareus]

On 06/17/2010 06:29 AM, Jeremy wrote:
> Hi,
> 
> When I'm programming, I find it immensely helpful to be able to plot audio
> data at different points in its processing, for debugging, and to test new
> ideas.
> 
> Essentially I want an oscilloscope, which plots each chunk of 1024 samples.
> 
> I've tried using libplot, but it seems too slow.  It's causing constant
> xruns, even when I only plot every 5th sample.
> 
> I thought that maybe libplot was too abstract, and that I needed to draw the
> pixels on the screen directly.  I tried using SDL, but it caused excessive
> xruns also.  Simply setting 48000 pixels per second was enough to cause the
> flow of xruns.  This is  *not* erasing the screen, just drawing the points.
>  I'd expect that erasing the screen is the slow part, but apparently not.
> 
> At this point I'm not sure if it's even possible to plot the audio data in
> realtime.  I did a rough calculation, that on my 2 Ghz cpu, it should have
> roughly 40,000 cycles to process each sample.  It seems to me that
> considering running the whole plugin only uses 1/4 of my cpu, the other
> 3 cycles should be plenty to put a pixel on the screen.
> 
> So I would guess that something else is the bottleneck, like my video chip,
> or maybe the libraries I'm using.
> 
> So basically my question is:  Has anyone else had any luck with plotting
> audio data in real time, and if so, how?  Is it not possible to plot every
> sample, but only a certain percentage of them?  Is there a fundamental
> restriction on doing so, or is my problem in software?
> 
> Jeremy

There's jack.scope that comes with jackd, jack_oscrolloscope[1] and
QoscC[2] which display the wave-form in realtime on-screen (but IIRC
won't save the graphic to file).
"bitscope" is nice for detecting value-range issues (sticky bits,
Nan..); "baudline" has a waveform option.. and a more generic
Oscilloscope: "xoscope"

As for "plotting" the signal: most audio-editors will do. just fire up
ardour or any sound-editor, record the signal & take a screenshot :)
Well, there's a couple of utilities to render wave-forms but all tools I
know there operate on files and not real-time.

http://apps.linuxaudio.org/apps/categories/scopes_and_realtime_visualizers


[1] http://das.nasophon.de/jack_oscrolloscope/
[2] http://flup.homelinux.org/qoscc.html
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[oauth] Re: liboauth and the oauth_verifier with twitter

[Robin Gareus]

On 06/17/2010 06:52 AM, Heath wrote:
> I'm trying to use liboauth to connect to twitter.  I can successfully
> retrieve my request token, but I cannot retrieve an access token
> because the liboauth functions do not accept the oauth_verifier
> parameter.  

sure it does, just add it to the request parameters..
You can also override other oauth_parameters (but for oauth_signature)
that way.

> Is twitter using non-standard oauth?  

No, it's using "OAuth 1.0A".
in short: The "A" adds the oauth_verifier.

> Is there a way to
> get this parameter into my request that I'm missing?

oauth_sign_url2("http://twitter...?a=b&oauth_verifier=CODE";...)

will do the trick.

ciao,
robin

-- 
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oa...@googlegroups.com.
To unsubscribe from this group, send email to 
oauth+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/oauth?hl=en.

Re: [LAD] Fwd: Re: SPOOFED: Re: meta issue tracker idea

[Robin Gareus]

On 06/14/2010 03:51 PM, Philipp wrote:
> --- Begin forwarded message from Philipp Überbacher ---
> From: Philipp Überbacher 
> To: Robin Gareus 
> Date: Mon, 14 Jun 2010 13:31:40 +0200
> Subject: Re: SPOOFED: Re: [LAD] meta issue tracker idea
> 
> Sorry, this message went to Robin only by accident.

I'm pasting my [off-list] reply in a similar fashion.

> Excerpts from Robin Gareus's message of 2010-06-13 14:14:13 +0200:
>> The motivations are clear - you may have gotten some details wrong (eg
>> Paul is working on quite a lot besides ardour) -  but the tenor is right.
> 
> What I meant was that he never implemented anything that could have
> solved the session management issue in ardour, be it lash, any of its
> predecessors or anything more recent. I know that torben worked on a
> jack_session patch for ardour, but as long as it's not in ardour it
> doesn't help much. The reasons for this could be manifold and I won't
> speculate at this point.
> 
>> The problem is: how to implement and maintain it? Just setting up a
>> tracker is easy; getting people to use and listen to it is the first
>> hurdle. Integrating it with upstream trackers the second.
>>
>> Do you know of a system up for the task that we can install without
>> large development on our side?
>>
>> If you have a good idea or elegant prototype, we can hook you up to
>> manage the tracker.linuxaudio.org vhost. None of the people involved in
>> LAO [1] are currently available for such a task; well, maybe Patrick is?!
>>
>> Cheers!
>> robin
>>
>> [1] http://lists.linuxaudio.org/pipermail/consortium/2010-April/002036.html
> 
> I think you're thinking more complicated than I did initially. Who says
> a custom tracker, the possibility of integration with upstream trackers
> and whatever other fancy stuff you guys came up with is really
> necessary? 

I doubt that many upstream authors will want to use "yet another
bugtracking/discussion" system.

The reasons may be manifold: it may not integrate nicely with source
revision tracking (which bug got fixed in which revision); it may not
integrate with existing bounty or donation systems, etc.

I appreciate the input and ideas and I agree that it would be
> nice, but necessary?

I'm just playing the devil's advocate here.

> Are you sure it's not more trouble than worth at
> this point? 

No but if we pull this off it should be useful from the beginning
otherwise it will not fly.

It does not to be perfect in it's first revision; but it must be good
enough to catch developer's interest.

> If a custom tracker should be developed at some point, then
> it shouldn't happen behind LAD doors but together with other parties who
> could benefit from it and likely have more expertise in that area.
> 
> The closest existing thing I know is http://openhatch.org/, which pulls
> all or some bugs from lots of trackers, but I'm not sure it's close to
> what is needed here.

AFAICT openhatch tackles a different problem: get people on a project. I
don't know if it can be useful for improving interoperability and
inter-project problems; but it could be a start.

> My idea for the near future was to simply use an existing wiki, possibly
> on linuxaudio.org (mainly because of the domain name). In the simplest
> form I believe, tags could be used for applications (to find all issues
> involving the specific app), pages for the issues and page subscriptions
> for notification. 

Those features are all already present at wiki.linuxaudio.org.

There's been some complaints about the current style; but no-one has
stepped forward and provided a better template yet. FWIW you can switch
the look&feel at http://wiki.linuxaudio.org/wiki/user/rgareus
the "experimental" there is a contender for the new default. but it's
not yet XHTML clean and requires javascript.

If one wants to pick up a project he/she can already find
http://wiki.linuxaudio.org/apps/categories/unmaintained
and
http://wiki.linuxaudio.org/apps/categories/dead_link


From the top-of-my head, here's how we could start:

go to http://wiki.linuxaudio.org/wiki/bugs/ISSUE

Where ISSUE eg: synchronization
- create or edit the wiki-page
- describe the problem
- add links to affected software
  eg. [[apps:all:ardour]], [[apps:all:hydrogen]]
- optionally add external links to upstream trackers.
- optionally add {{rss>TRACKER-FEED-URL}} for issue upstream.

The backlinks ("what links here") feature of the eg.
http://wiki.linuxaudio.org/apps/all/hydrogen
page will show related bugs. It will be easy to make a "show only
backlinks in the 'bug' namespace" feature.)

Once we have a few test/example pages we can add wiki-

Re: [LAD] meta issue tracker idea

[Robin Gareus]

On 06/10/2010 04:11 AM, Patrick Shirkey wrote:
> 
> On Tue, June 8, 2010 1:35 pm, Robin Gareus wrote:
>> On 06/08/2010 10:31 AM, Patrick Shirkey wrote:
>>>
>>> On Mon, June 7, 2010 8:09 am, Robin Gareus wrote:
>>>> On 06/07/2010 05:26 AM, Patrick Shirkey wrote:
>>>>>
>>>
>>>>> But that is
>>>>> really just replicating existing functionality. A more productive
>>>>> approach
>>>>> is to improve on the bugs page now that it exists. For example an
>>>>> "add"
>>>>> /
>>>>> "submit" new feed button/link would be helpful.
>>>>
>>>> There's a 'tiny' link labeled "FAQ & Subscribe" in the bar on the
>>>> right.
>>>>
>>>
>>> That should be good enough for most people.
>>>
>>>
>>>> I don't think automating the submit/add system is a good idea; Marc,
>>>> Ico
>>>> & me are are quite quick filtering SPAM and editing the planetplanet
>>>> config-file.
>>>>
>>>
>>> Agreed.
>>>
>>>> We'll need to update the wiki-page though and improve the HTML-template
>>>> for "planet bug". Anyway so far it's just an experiment, not a
>>>> maintained service.
>>>>
>>>
>>> It's looking quite useful already. Another idea is to aggregate the bugs
>>> as they are fixed and maintain a record for the most active projects. I
>>> s'pose most of that data can be extracted directly from the trackers? As
>>> in no need for us to write a database specifically for that info.
>>>
>> Alas that's not so simple with most systems.
>> Only trac is good at that - providing a feed or statistics for recently
>> resolved and closed bugs, that is.
>>
>> MantisBT requires the administrator to create a filter [1] and I don't
>> think it's even possible with the sourceforge tracker. SF.net provides
>> their own statistics but there's no feed for those.
>> If googlecode-issue-tracker can do it it's a feature well hidden.
>> I have not checked flyspray, bugzilla and debbugs.
>>
>> so long,
>> robin
>>
>> [1]
>> http://www.futureware.biz/blog/index.php?title=rss_feeds_in_mantis_1_0_0a3&more=1
>>
> 
> That makes that idea fairly difficult to implement in the short term.
> 
> So far we have the list of apps being tracked on the right hand column,
> and add/submit link and the actual feeds. You suggested an extension that
> allows tickets to be tracked cross app but I think that is a lot of effort
> for minimal gain at this point as there isn't yet a huge user base for the
> tracker portal.
> 
> I think it would be useful for the idea if we could bring out the user
> contribution side a little more before building code to handle cross app
> bug tracking.
> 
> Maybe a few links to add a new ticket, join the project and donate if the
> project has that facility that could be displayed next to each project
> and/or item in each feed?
> 
Adding extra information is not a big deal. The problem is: All trackers
require a user to log in in order to access the "submit ticket" page..
and the minority of them has OpenID or OAuth enabled.

Clicking on the link in the "Subscriptions" sidebar already gets you to
the main site of each trackers from where you can proceed to "add
ticket" if you're logged in there.

If you want to go ahead and improve the layout: I can give you write
permissions on linuxaudio.org:/var/lib/planet/templates/ and
/etc/planet-bugs.conf

One idea would be to create a linuxaudio account on all upstream
trackers and provide a form on LAO that submits tickets upstream using
this account; but it'd be a major task to do so: SPAM filtering,
aggregate upstream versions & options; templates for the multitude of
different trackers out there etc etc, not to mention handling email
notifications that come back from the trackers.

2c,
robin



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] meta issue tracker idea

[Robin Gareus]

On 06/13/2010 12:42 PM, Philipp Überbacher wrote:
> Excerpts from Philipp's message of 2010-06-05 13:18:02 +0200:
>> Hi,
>> this is all about making Linux Audio more useful.
>> The idea came about because on the one hand there are parts of Linux
>> audio that really need some coders attention and on the other hand there
>> are coders who don't know where to start. I realize that there never are
>> more than enough coders, so this is mainly about bringing attention to
>> the parts that need it the most.
>>
>> To a degree it's what bug/feature trackers are there for, but those are
>> usually per application, and while there are category and priority
>> systems in place those are rarely used.
>> So what this is also about is bridging a gap between users, developers
>> and between applications.
>>
>> It would be quite simple really.
>> An easy to find, central place, possibly a wiki or a tracker.
>> Anyone, a user most likely, describes his workflow and what the
>> showstopper is. This could be applications not syncing properly, or an
>> essential but missing feature. The idea is to tackle mainly
>> infrastructure and cross application problems, with the goal to make a
>> workflow actually work.
>> The user should have to specify all relevant information available, such
>> as version information, links, probably some kind of priority or urgency
>> indication and how hard he believes it would be.
>> He could also put up a reward of sorts, not necessarily monetary.
>> Any developer could pick up the task and work on it, possibly leaving a
>> notice.
>>
>> The possible benefits I see are:
>> a) A kind of overview of what's needed the most, one place where you can
>> see what's actually important to users.
>> b) A way to identify and fix problems between applications - something I
>> believe is very important for a system that encourages the use of
>> multiple applications at once. I believe there are numerous
>> synchronisation/transport issues for example which are never really tackled,
>> despite this being a very important part of the infrastructure.
>> c) Emphasis on actual workflow and usability.
>> d) It would work for any program, even those without tracker and those
>> that aren't high profile and aren't usually in the center of attention.
>>
>> Could this work? What do you think?
>> -- 
>> Regards,
>> Philipp
> 
> Hi guys,
> first of all, as usual in the German language area, I'll apologize
> beforehand. I left you alone with the idea on purpose, but didn't plan
> to do so for so long. Also sorry for replying to my own mail. I feel
> like I have to make the origin of the idea and my intentions clear, in
> the process of doing so I'll likely offend someone, which is not my
> intent, I appreciate and value the work put into Linux Audio by all of
> you.
> 
> One reason for coming up with the idea is that I'd like to see user
> wishes like jack support for mumble for the podcasters and jack support
> for asterisk for the blind, like Julien, come true. Chances that the
> main developers implement and maintain jack support in their apps are
> slim at best, but you LADs have the expertise to make it happen.
> 
> Another small reason are new developers. They rarely know where to
> start, which app to get involved in etc.. This meta tracker could
> possibly help to guide them to projects and tasks where help is needed
> and appreciated.
> 
> The most important reason however is that Linux Audio currently doesn't
> fulfill its promise as modular system, but the goal seems to be in
> reach. I know this is a bit of a bold claim, but I have at least some
> evidence to back it.
> 
> The backbone of the modular Linux Audio system is jack, yet it's creator
> develops a huge monolithic piece of software and has, to my knowledge,
> never actively supported any of the attempts of solving the session
> management issue. I'd like to claim here that any modular system, in
> order to be useful, needs the things: connections (jack),
> synchronisation (jack transport) and a means of storing and recalling
> the setup. The last part has apparently been worked on for a long time,
> but no overall satisfactory solution has come out of it. But now there
> are two attempts that could fulfill this role. Each with its benefits
> and drawbacks and neither is able to fulfill the role completely yet.
> But they are not mutual, they could live side by side, so there seems
> little in the way of Linux Audio working as it's supposed to.
> 
> With this goal in reach, another class of problems will become more
> visible, namely issues between applications. By this I mean mainly
> synchronisation issues of all kinds. Since it's usually unclear where
> the issue stems from, developers on either side tend to dismiss it and
> claim that the other app is buggy. One notable example I believe is jack
> transport synchronisation between ardour and hydrogen. It took a number
> of months at least to resolve it, if it is resolved. During that time
> funny

Re: [LAD] [LAU] like "qjackctl", but trimmed of all fat

[Robin Gareus]

On 06/09/2010 04:07 AM, Aaron Krister Johnson wrote:
> Hi all,
> 
> Let me know how this newer version works out for you. I've hopefully made
> the audio/MIDI distinction cleaner and bug-free, b/c now the script uses
> 'jack_lsp -t' to list the type. One can toggle between alsa-midi and
> jack-midi with the 'm' key.
> 
> Not being a user of a2jackmidi bridge or whatever that program is, I cannot
> vouch for how this works with it...does anyone want to try it out and let me
> know?
> 
> http://www.akjmusic.com/software/jackctl20100604.py

I get a "nonsense!!!" message as soon as there's any jack-port with a
whitespace in its name; otherwise it seems to work fine now.

-8<---
$ jack_lsp -c -t
system:capture_1
32 bit float mono audio
system:capture_2
32 bit float mono audio
system:playback_1
   MPlayer [14906]:out_0
32 bit float mono audio
system:playback_2
   MPlayer [14906]:out_1
32 bit float mono audio
MPlayer [14906]:out_0
   system:playback_1
32 bit float mono audio
MPlayer [14906]:out_1
   system:playback_2
32 bit float mono audio
a2j:Midi Through [14] (capture): Midi Through Port-0
8 bit raw midi
a2j:Midi Through [14] (playback): Midi Through Port-0
8 bit raw midi

$ jackctl.py
Welcome to jackctl. 'h' at the prompt gives help
jackctl(audio)--> l
nonsense!!!
jackctl(audio)--> m
jackctl(midi)--> l
nonsense!!!
jackctl(midi)--> q
Goodbye!
-8<---
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] two reasons for jack2 .. and the problems with it.

[Robin Gareus]

Hi again,

All right, Rui was (yet again) very quick on the uptake and qjackctl
0.3.6.24 is out. I managed to get a system where JACK sessions not only
survive system suspend/resume cycles but also qjackctl does. YAY.

It still required quite a bit of scripting to remember port-connections
and setup-parameters.. but the myjackctl.sh script that came to be for
that purpose also allows to switch jackdmp-backends in one go (otherwise
it'd be a few successive jack_control commands).

I've collected the scripts and a small HowTo at
http://rg42.org/wiki/jack2contol

have fun,
robin

PS. So far it's only tested on a single machine.. once there's some
feedback, a setup-script or package is the next step.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] meta issue tracker idea

[Robin Gareus]

On 06/08/2010 10:31 AM, Patrick Shirkey wrote:
> 
> On Mon, June 7, 2010 8:09 am, Robin Gareus wrote:
>> On 06/07/2010 05:26 AM, Patrick Shirkey wrote:
>>>
> 
>>> But that is
>>> really just replicating existing functionality. A more productive
>>> approach
>>> is to improve on the bugs page now that it exists. For example an "add"
>>> /
>>> "submit" new feed button/link would be helpful.
>>
>> There's a 'tiny' link labeled "FAQ & Subscribe" in the bar on the right.
>>
> 
> That should be good enough for most people.
> 
> 
>> I don't think automating the submit/add system is a good idea; Marc, Ico
>> & me are are quite quick filtering SPAM and editing the planetplanet
>> config-file.
>>
> 
> Agreed.
> 
>> We'll need to update the wiki-page though and improve the HTML-template
>> for "planet bug". Anyway so far it's just an experiment, not a
>> maintained service.
>>
> 
> It's looking quite useful already. Another idea is to aggregate the bugs
> as they are fixed and maintain a record for the most active projects. I
> s'pose most of that data can be extracted directly from the trackers? As
> in no need for us to write a database specifically for that info.
> 
Alas that's not so simple with most systems.
Only trac is good at that - providing a feed or statistics for recently
resolved and closed bugs, that is.

MantisBT requires the administrator to create a filter [1] and I don't
think it's even possible with the sourceforge tracker. SF.net provides
their own statistics but there's no feed for those.
If googlecode-issue-tracker can do it it's a feature well hidden.
I have not checked flyspray, bugzilla and debbugs.

so long,
robin

[1]
http://www.futureware.biz/blog/index.php?title=rss_feeds_in_mantis_1_0_0a3&more=1
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] mailing-list problems - was: axonlib (last one)

[Robin Gareus]

On 06/08/2010 09:07 PM, Chris Cannam wrote:
> On Tue, Jun 8, 2010 at 7:21 PM, ccernn  wrote:
>> hmmm, i have a reply, and a reply-to-all, but no reply-to-list
> 
> Reply-to-all will work, then.
> 
> Some people get cross if you reply-to-all to one of their list
> messages, because that means they may get two copies of your reply --
> one to them directly and one via the list.  That does depend on their
> mailer or mail server though, because the two have identical message
> IDs and so can be handled correctly if their client is up to it.

It also depends on the settings you choose when subscribing to the list.
You can change them by visiting
  http://lists.linuxaudio.org/options/linux-audio-dev
or follow the link at the end of each list-email and use the
"unsubscribe or edit options" button there.

At the bottom of there's an option:
-=-=-=-=-
Avoid duplicate copies of messages?

When you are listed explicitly in the To: or Cc: headers of a list
message, you can opt to not receive another copy from the mailing list.
Select Yes to avoid receiving copies from the mailing list; select No to
receive copies.
-=-=-=-=-

> (I'm
> using reply-to-all now, so you'll soon find out if your client copes.
> If you're using gmail, I think it will, and you will get only a single
> copy of this.)
> 
> So: reply-to-list is better if you have it, but if you don't, use 
> reply-to-all.
>
> Chris

mmh "better" in what way?

I'm certainly not the only one with a setup where emails from the list
are moved directly into a dedicated folder which I read at convenience.
Whereas emails to me end up in the INBOX which I read more frequently.

I tend to use the 'reply-to-list' and 'reply-to-all' correspondingly:
"important replies" to-all; else to-list only.

2c,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] mailing-list problems - was: axonlib (last one)

[Robin Gareus]

On 06/08/2010 05:11 PM, ccernn wrote:
> sorry...
> no 'reply' butttons (thunderbird)

Thunderbird 3.0.4  has reply-to-all and reply-to-list buttons.
They are displayed by default. Maybe you've 'customized' them away?

> or any other link (list archives) 

The top-most (aka first) link in the email-archive is a 'mailto:' URL
which opens a window to send a reply to the list. It does not cite the
message but it includes the in-reply-to header.

eg.
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2010-June/027951.html

> i tried has worked so far, so i give up.
> i don't have the patience for these things...
> at least i tried..

There are a few thousand subscribers to this list which have no problem
at using the "reply to all" or "reply to list" button or shortcut.

Sorry to hear that you're running into problems. I wonder why our
list-admin (CCed) has not yet replied to this - probably because the
Subject is misleading - If you're interested why the default reply does
not go to the list, read: http://www.unicom.com/pw/reply-to-harmful.html

It looks like you just claimed the: "You're the 1th subscriber and
win the reply-to-list problem" award (-:

> i just wanted to let you know that there's something new out there, that
> some of you might find interesting, that's all...

Thanks for sharing.

Once you're over the initial email-list frustration, you may want to
announce it on http://lists.linuxaudio.org/listinfo/linux-audio-announce
Doing so should be easier: LAA is a one-way email-list: no replies and
it would help to gain publicity for axonlib. There's quite a few
news-feeds, packagers and software indexers/archivers watching there.

> if there's any questions, ask in our discussion group instead
> (http://groups.google.com/group/axonlib), or email me directly...
> or in the discussion thread over at kvr-audio
> (http://www.kvraudio.com/forum/viewtopic.php?t=28)
> - ccernn

Cheers!
robin

PS. there are various 3rd Party services that allow to post to this
email-list using just a web-browser. Some even look like a web-forum:
eg. http://blog.gmane.org/gmane.linux.audio.devel
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] qjackctl & server name

[Robin Gareus]

On 06/08/2010 12:04 AM, Rui Nuno Capela wrote:
> On 06/07/2010 08:24 PM, Robin Gareus wrote:
>> On 06/07/2010 02:59 PM, Rui Nuno Capela wrote:
>>> On Mon, 7 Jun 2010 08:18:23 -0400, drew Roberts 
>>> 
>>
>>>> In cases where it might connect on startup, must it?
>>>>
>>>
>>> no. again it only connects automatically iif a (default) server is
>>> found responsive to open qjackctl as one of its clients.
>>
>> It must be even more exclusive. I have a responsive default server
>> running and qjackctl does not connect to it.
>>
>> Please define "responsive to open qjackctl";
>> It certainly responds to ardour2, mplayer, jack-rack, patchage...
>>
> 
> maybe i messed "responsive" by "responsible"
> 
> anyway, the said general default jack server name is literally "default".
> 
> if you start the server for instance via `jackd -n fooserver ...` then
> this server in particular will be identified by "fooserver". then you
> will only connect to it as a client if either your application program
> calls jack_client_open("barclient", JackServerName, "fooserver") or you
> have previously set JACK_DEFAULT_SERVER=fooserver to override the
> default name (which is, uh, "default").
> 
> similarly, if this `jackd -n fooserver ...` server instance is already
> found running, qjackctl will connect to it iif it's launched via
> `qjackctl -n fooserver` or JACK_DEFAULT_SERVER=fooserver is properly set.
> 
> nb. when qjackctl attaches on startup to an already running jack server,
> it doesn't give a damn nor matter to which device preset you have
> configured within qjackctl settings. look, a matching jackd server name
> is found already active and most probably it has been started with some
> other means than qjackctl, so devices may differ.
> 

this is getting a bit OT here, but..

in my case it does not; qjackctl is already running and started jackd in
the first place, it disconnected from that jackd when changing the
driver-backend.

Then I press "start" in qjackctl again and it launches a new server
instead of re-connecting. The server-name has not changed (it's still
'default').

Reproduce:

use qjackctl to start a jackdmp on alsa hw:0
# jack_control dps device hw:1
# jack_control sm
qjackctl disconnects

Press start in qjackctl -> it launches a 2nd jackd (on hw:0).

What works is to disconnect qjackctl (but keep jackd running) before
calling jack_control. Switch the Qjackctl Preset to match the hw:1
and "press start" in qjackctl after the `jack_control sm`.

Hence the patch I sent you earlier to that makes qjackctl
react on DBUS  org.rncbc.qjackctl.loadpreset int32:

robin


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] qjackctl & server name

[Robin Gareus]

On 06/07/2010 02:59 PM, Rui Nuno Capela wrote:
> On Mon, 7 Jun 2010 08:18:23 -0400, drew Roberts 
> 
>> 
>> Hold on a second. Let me try walking through this.
>> 
>> We start qjackctl. Does it connect to a jack server at this point?
>> If so,
>> always or only if jack is currently running.
>> 
> 
> it connects only if jackd is currently running.

..and if the interface the running jackd uses matches the one in the
currently active qjackctl setup.

qjackctl (0.3.6.22 and jackd-1.9.6) here launches a new jackd even if
jackd is running but using a different interface (eg. jackd is using
hw:1 and the activated qjackctl setup says hw:0)

I'd like qjackctl to always connect to an existing server if the
jack-server name matches (see the "two reasons for jack2" thread).

Is that possible?

>> In cases where it might connect on startup, must it?
>> 
> 
> no. again it only connects automatically iif a (default) server is
> found responsive to open qjackctl as one of its clients.

It must be even more exclusive. I have a responsive default server
running and qjackctl does not connect to it.

Please define "responsive to open qjackctl";
It certainly responds to ardour2, mplayer, jack-rack, patchage...

>> Let's say no jack is running and we start qjackctl. Let's say it
>> doesn't connect to jack at this point.
> 
> i does not.
> 
> 
>> Could there not be a setup option to indicate what -n indicated
>> now?
>> 
> 
> qjackctl -n command line option is just convenient for you to start
> jackd server with that precise server name and let qjackctl connect
> immediately to it as client to that same server.
> 
> 
>> Let's say multiple jacks are running and we start qjackctl. Is it
>> possible to discover that multiple jacks are running?
> 
> nope. qjackctl will only "see" the default jack server or the one
> named by JACK_DEFAULT_SERVER environment variable at the time
> qjackctl is launched.
> 
> 
>> If so, would it be possible to allow a choice from within the gui
>> as to which one to connect to?
>> 
> 
> none atm. each qjackctl instance may only attach to one server at a
> time.
> 
> cheers
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] two reasons for jack2 .. and the problems with it.

[Robin Gareus]

I forgot to mention:

$jackd --version
jackdmp 1.9.6
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2009 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
no message buffer overruns
no message buffer overruns
jackdmp version 1.9.6 tmpdir /dev/shm protocol 8

..and I got it from debian:
 Package: jackd
 Priority: optional
 Section: sound
 Installed-Size: 724
 Maintainer: Debian Multimedia Maintainers

 Architecture: i386
 Source: jack-audio-connection-kit
 Version: 1.9.5~dfsg-13


qjackctl & patchage were compiled from source using the latest sources
as of mid-last week (June 3).

robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] two reasons for jack2 .. and the problems with it.

[Robin Gareus]

On 06/07/2010 10:29 AM, Stéphane Letz wrote:
> 
> Le 7 juin 2010 à 01:49, Robin Gareus a écrit :
> 
>> Well I did the switch: jackd here is now jackdmp.. and [almost]
>> everything works just like before.
>>
>> The motivation for this was to benefit from the re-loadable backend
>> feature of jackdmp for two reasons:
>>
>> - to be able to quickly switch between internal and external soundcards
>> - have JACK sessions survive suspend/resume cycles (using dummy backend)
>>
>> After some initial testing I was quite enthusiastic. It looks very
>> smooth on the surface. but - or course - the devil is in the details:
>>
>> Calling `jack_control sm` drops existing connections to system:* ports.
>> OK. They may be different but here they're not. no problem: this can be
>> remedied with a simple shell script.
>> But worse: both patchage (v0.4.4) & qjackctl (v0.3.6.22) go haywire
>> (either 100% CPU usage,  disconnect or crash) when replacing the
>> back-end while they're running. I have not yet found a pattern in the
>> app's behaviour.
> 
> Any log to help finding if jack2 is the problem?

I don't think it is. jack2 continues to run & play just fine.

The only messages in ~/.log/jack/jackdbus.log are:

 ERROR: Failed to find port 'system:playback_1' to [dis]connect
 ERROR: Failed to find port 'system:playback_2' to [dis]connect

Maybe this is related to the way patchage/qjackctl handle port
connections?! They hit a NULL pointer and then either crash or end up in
some funny state..

However jack2/dbus live-locks if I don't switch it to the dummy
interface before suspending the machine. jack1 just exits and jackdmp
produces tens of thousands of
 ALSA: channel flush for playback failed (File descriptor in bad state)
 JackAudioDriver::ProcessAsync: read error, skip cycle

error message which probably explain the live-lock.
That is also weird, because I've started 'jackd -S' so why would I get
ProcessAsync. Maybe the '-S' option is not passed through to jackdbus?!
I'll investigate..

In some earlier experiments I've seen jack2 crash; I've attached the
log, but jackdmp is not compiled with --debug so I'm not sure if they're
helpful.


>>
>> Qjackctl's issue can be worked around by stopping it before doing the
>> switch: 'dbus-send --system /org/rncbc/qjackctl org.rncbc.qjackctl.stop'
>> but re-starting it after the switch fails if the qjackctl setup does not
>> match the current active hardware (it tries to start a 2nd jackd
>> instead); otherwise it works just fine.
>>
>> ardour2 disconnects if I switch directly between two alsa backends.
>> however going alsa,hw:0 -> dummy -> alsa,hw:1 works.
>>
>> Clearly there's some issue remaining to be worked out.
>>
>> The good news: both mplayer and alsa-plug have no problem with me
>> changing the jackd-backend (while retaining sample-rate and buffersize)
>> even while they're playing; so I'm good most of the time :)
>>
>> The scripts I use are available at http://rg42.org/wiki/jack2contol
>>
>> Has anyone else ventured down that road and has a similar setup running?
>> Can someone reproduce these problems?
>>
>> Cheers!
>> robin
> 
> 
> Stéphane 
Thu Jun  3 21:02:45 2010: ESC[1mESC[31mERROR: Failed to find port 
'system:playback_1' to [dis]connectESC[0m
Thu Jun  3 21:02:45 2010: ESC[1mESC[31mERROR: Failed to find port 
'system:playback_2' to [dis]connectESC[0m
Thu Jun  3 21:02:51 2010: Client 'system' with PID 0 is out
Thu Jun  3 21:02:51 2010: Released audio card Audio1
Thu Jun  3 21:02:51 2010: ESC[1mESC[31mERROR: Segmentation Fault!ESC[0m
Thu Jun  3 21:02:51 2010: ESC[1mESC[31mERROR: info.si_signo = 11ESC[0m
Thu Jun  3 21:02:51 2010: ESC[1mESC[31mERROR: info.si_errno = 0ESC[0m
Thu Jun  3 21:02:51 2010: ESC[1mESC[31mERROR: info.si_code  = 1 
(SEGV_MAPERR)ESC[0m
Thu Jun  3 21:02:51 2010: ESC[1mESC[31mERROR: info.si_addr  = 0xcESC[0m
Thu Jun  3 21:02:51 2010: ESC[1mESC[31mERROR: reg[00]   = 0x0033ESC[0m
Thu Jun  3 21:02:51 2010: ESC[1mESC[31mERROR: reg[01]   = 0xESC[0m
Thu Jun  3 21:02:51 2010: ESC[1mESC[31mERROR: reg[02]   = 0x007bESC[0m
Thu Jun  3 21:02:51 2010: ESC[1mESC[31mERROR: reg[03]   = 0x007bESC[0m
Thu Jun  3 21:02:51 2010: ESC[1mESC[31mERROR: reg[04]   = 0x080a752fESC[0m
Thu Jun  3 21:02:51 2010: ESC[1mESC[31mERROR: reg[05]   = 0x080a4527ESC[0m
Thu Jun  3 21:02:51 2010: ESC[1mESC[31mERROR: reg[06]   = 0xbf837b80ESC[0m
Thu Jun  3 21:02:51 2010: ESC[1mESC[31mERROR: reg[07]   = 0xbf837b3cESC[0m
Thu Jun  3 21:02:51 2010: ESC[1mESC[31mERROR: reg[08]   = 0xb75efff4ESC[0m
Th

Re: [LAD] meta issue tracker idea

[Robin Gareus]

On 06/07/2010 02:26 PM, drew Roberts wrote:
> On Sunday 06 June 2010 18:06:43 Robin Gareus wrote:
>> Anyway, this is a one-way system. Users will need to use
>> upstream-trackers to submit information. This somehow undermines the
>> idea of providing feedback for interop issues at a central location.
> 
> Just a central account function would be very helpful. Register at 
> tracker.linuxaudio.org and be able to submit to any upstreams tracker with 
> that one account.

With OAuth and OpenID this is possible; but not all trackers support
those standards; besides it only solves a side issue: user-accounts.
Singing up on each tracker is a one-time only job and much easier than
filing a proper bug report; so that part can actually be neglected.

Let's play through an example:

1) you file a bug report concerning sync between Ardour & Hydrogen
   on tracker.linuxaudio.org
2) the tracker automatically forwards those bugs upstream using your
   account.
3) On the Ardour tracker there's a quick response saying it's a problem
   with JACK-latency compensation in Hydrogen and the ticket is closed
   there.
4) tracker.lao recognizes that update and forwards the comment to the
   hydrogen bug-tracker

step (2) could be done if upstream tackers support OAuth;
there's a module for Trac and Mantis; but none for Bugzilla yet.
sf.net apparently has it's own interface that allows to forwards bugs.
I dunno about gna.org.
NTL it'll be some work to come up with templates for all those systems.

step (4) will tricky It requires correlating information from step (1,2)
and interpreting the reply from step (3).

Developing such a system will be at least a week of full-time work and
then a few months to test, debug and style it; not including getting
some patches upstream into trackers who require it.

Well, I don't think LAO would be the only community interested in having
such a setup. A quick google-search did not reveal a similar FLOSS
system; did any of you guys stumble over something like that?

ciao,
robin

> all the best,
> 
> drew
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] meta issue tracker idea

[Robin Gareus]

On 06/07/2010 05:26 AM, Patrick Shirkey wrote:
> 
>> On 06/06/2010 12:33 AM, Geoff Beasley wrote:
>>> On 06/06/2010 04:58 AM, Patrick Shirkey wrote:

 I like this idea and I can see a place for it at Linuxaudio.org. A
 centralised feature/bug/infrastructure tracker.
>>
>> If someone wants to step forward, hosting it under the umbrella (and on
>> the server) of linuxaudio.org will be the least issue.
>>
 I think the hardest part will be to isolate the most important
 information
 and present it in a very obvious way. This could easily get left high
 and
 dry by making the system too complex for the info that is being
 aggregated.
>>
>> Bug-tracking always requires user & developer interaction (confirm,
>> reproduce, comment..). Merly aggregating or collecting information won't
>> do much good.
>>
> 
> The feeds provide a link through to the original post so that provides a
> way back for contributors and developers.
> 

Yeah, but only one at a time; this is not a "meta tracker".

>> OTOH I really like the idea to improve interoperability between apps.
>>
 A way to start the system could be to collate the info using rss feeds
 from the various bug trackers that are already in use.
>>
>> Testing this idea: http://planet.linuxaudio.org/bugs/
>> currently collects [only] ardour, jack & qtractor tracker's feeds.
>> Imagine how this would look with over 50 projects. I doubt it would be
>> very useful. But things could be improved by using more elaborate
>> RSS/Atom feed queries..
>>
>> Anyway, this is a one-way system. Users will need to use
>> upstream-trackers to submit information. This somehow undermines the
>> idea of providing feedback for interop issues at a central location.
>>
>> The easiest way to supplement this would be a linux-audio-bugs
>> email-list or just re-use this list.
>>
> 
> The bugs feeds is a good start. Did you just set that page up?

yes; well we have this planet for a few months now (Nov 2009).
see http://wiki.linuxaudio.org/wiki/planet

Making this 2nd planet with feeds from trackers took less than 5 mins.
It's rather a quick experiment to see if something like this can be useful.

> I don't like the idea of flooding this list with bug reports. A new list
> is an option using the feeds from the bugs page as data.

I meant a list for discussion and commenting on bugs, not for
auto-posting/forwarding new bug request there.

> But that is
> really just replicating existing functionality. A more productive approach
> is to improve on the bugs page now that it exists. For example an "add" /
> "submit" new feed button/link would be helpful.

There's a 'tiny' link labeled "FAQ & Subscribe" in the bar on the right.

I don't think automating the submit/add system is a good idea; Marc, Ico
& me are are quite quick filtering SPAM and editing the planetplanet
config-file.

We'll need to update the wiki-page though and improve the HTML-template
for "planet bug". Anyway so far it's just an experiment, not a
maintained service.

>>> linuxaudio.org would indeed be a good place for such a tracker, and it
>>> is indeed a good idea but for the issue of 'updatedness' ie; it would
>>> need quite some effort to remain up-to-date and therefore relevant and
>>> useful. If it slipped behind it could in fact have the opposite effect.
>>> who would be prepared to undertake such a burden? it would need to be
>>> completely automated as the amount of info could be quite substantial
>>> quite quickly... seems to me the devil is in the detail.
>>
>> Indeed. Implementing a centralized cross-project bug & feature tracker
>> - possibly with bounties - can become quite complex; not to mention it
>> requires quite some effort to maintain it.
>>
>> Please proof me wrong. It'd be a great thing to have.
>>
> 
> I think you are correct. The trick is figuring out how to move the concept
> forward without getting bogged down in minor details.
> 
let's keep brainstorming.

robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] two reasons for jack2 .. and the problems with it.

[Robin Gareus]

Well I did the switch: jackd here is now jackdmp.. and [almost]
everything works just like before.

The motivation for this was to benefit from the re-loadable backend
feature of jackdmp for two reasons:

- to be able to quickly switch between internal and external soundcards
- have JACK sessions survive suspend/resume cycles (using dummy backend)

After some initial testing I was quite enthusiastic. It looks very
smooth on the surface. but - or course - the devil is in the details:

Calling `jack_control sm` drops existing connections to system:* ports.
OK. They may be different but here they're not. no problem: this can be
remedied with a simple shell script.
But worse: both patchage (v0.4.4) & qjackctl (v0.3.6.22) go haywire
(either 100% CPU usage,  disconnect or crash) when replacing the
back-end while they're running. I have not yet found a pattern in the
app's behaviour.

Qjackctl's issue can be worked around by stopping it before doing the
switch: 'dbus-send --system /org/rncbc/qjackctl org.rncbc.qjackctl.stop'
but re-starting it after the switch fails if the qjackctl setup does not
match the current active hardware (it tries to start a 2nd jackd
instead); otherwise it works just fine.

ardour2 disconnects if I switch directly between two alsa backends.
however going alsa,hw:0 -> dummy -> alsa,hw:1 works.

Clearly there's some issue remaining to be worked out.

The good news: both mplayer and alsa-plug have no problem with me
changing the jackd-backend (while retaining sample-rate and buffersize)
even while they're playing; so I'm good most of the time :)

The scripts I use are available at http://rg42.org/wiki/jack2contol

Has anyone else ventured down that road and has a similar setup running?
Can someone reproduce these problems?

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] meta issue tracker idea

[Robin Gareus]

On 06/05/2010 11:50 PM, drew Roberts wrote:
> On Saturday 05 June 2010 14:40:35 Ray Rashif wrote:
>> The only assurance
>> is a monetary bounty system.

I disagree.

> Might be possible to leave out the monetary bit at least. How about credits 
> on 
> a musicians next release as a bounty for instance? Other way out bounties?
> 
whatever. Just don't force money on people who don't want it.

Money corrupts.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] meta issue tracker idea

[Robin Gareus]

On 06/06/2010 12:33 AM, Geoff Beasley wrote:
> On 06/06/2010 04:58 AM, Patrick Shirkey wrote:
>>
>> I like this idea and I can see a place for it at Linuxaudio.org. A
>> centralised feature/bug/infrastructure tracker.

If someone wants to step forward, hosting it under the umbrella (and on
the server) of linuxaudio.org will be the least issue.

>> I think the hardest part will be to isolate the most important
>> information
>> and present it in a very obvious way. This could easily get left high and
>> dry by making the system too complex for the info that is being
>> aggregated.

Bug-tracking always requires user & developer interaction (confirm,
reproduce, comment..). Merly aggregating or collecting information won't
do much good.

OTOH I really like the idea to improve interoperability between apps.

>> A way to start the system could be to collate the info using rss feeds
>> from the various bug trackers that are already in use.

Testing this idea: http://planet.linuxaudio.org/bugs/
currently collects [only] ardour, jack & qtractor tracker's feeds.
Imagine how this would look with over 50 projects. I doubt it would be
very useful. But things could be improved by using more elaborate
RSS/Atom feed queries..

Anyway, this is a one-way system. Users will need to use
upstream-trackers to submit information. This somehow undermines the
idea of providing feedback for interop issues at a central location.

The easiest way to supplement this would be a linux-audio-bugs
email-list or just re-use this list.

> linuxaudio.org would indeed be a good place for such a tracker, and it
> is indeed a good idea but for the issue of 'updatedness' ie; it would
> need quite some effort to remain up-to-date and therefore relevant and
> useful. If it slipped behind it could in fact have the opposite effect.
> who would be prepared to undertake such a burden? it would need to be
> completely automated as the amount of info could be quite substantial
> quite quickly... seems to me the devil is in the detail.

Indeed. Implementing a centralized cross-project bug & feature tracker
- possibly with bounties - can become quite complex; not to mention it
requires quite some effort to maintain it.

Please proof me wrong. It'd be a great thing to have.

robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [oauth] 2 legged oauth

[Robin Gareus]

On 06/06/2010 07:00 PM, Carlos wrote:
> Hi, I implemented a REST client library that I have successfully
> tested against MySpace.com and when trying to test against other
> containers like Orkut, iGoogle, Hi5 and else I got troubled when
> getting "invalid signature" in all of them. While the development
> support is available, not all of them have an answer nor a hint, so I
> am not only making a hard way learning every container looks
> different, but now being interested in connecting to kind of
> referennce site or lab where tne server side implementation is right
> designed in compliance to the standard but with some human behind with
> the right expertise. Is this too much asking or am I dreaming?
> 
> Regards, Carlos
> 

some reference test-servers:
  http://term.ie/oauth/example/
  http://sevengoslings.net/~fangel/oauth-explorer/
the "humans behind" them are subscribed to this list.

There might even be be more; search the list-archive for "test server".

http://wiki.oauth.net/TestCases might also come in handy.
and there's http://googlecodesamples.com/oauth_playground/

HTH,
robin

-- 
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oa...@googlegroups.com.
To unsubscribe from this group, send email to 
oauth+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/oauth?hl=en.

Re: [oauth] Compiler Error on Mac OSX 10.6.3

[Robin Gareus]

Hi Heath,

Let's take this off-mailing-list; we're facing some compiler/linker
issues which is beyond OAuth discussion. Let's report back there when
we're done, shall we?

Let me recap: You've successfully compiled liboauth (ls src/.libs/*.a)
and encounter an error when linking the test/example code.

On 06/02/2010 07:59 AM, Heath Borders wrote:
> I'm having problems specifying proper curl libs to make oauth now.
> 
> I've configured using the following command (please let me know if I
> did any overkill):
> 
> ./configure CFLAGS="-arch i386" LDFLAGS=-L`cd ../palm-i386/lib/; pwd`
> CPPFLAGS=-I`cd ../palm-i386/include/; pwd` --prefix=`cd ../palm-i386/;
> pwd` --build=i386 --host=i386 --disable-shared --disable-nss
> CURL_CFLAGS="-arch i386 -I"`cdmcheath:liboauth-0.8.6 hborders$
> ./configure CFLAGS="-arch i386" LDFLAGS=-L`cd ../palm-i386/lib/; pwd`
> CPPFLAGS=-I`cd ../palm-i386/include/; pwd` --prefix=`cd ../palm-i386/;
> pwd` --build=i386 --host=i386 --disable-shared --disable-nss
> CURL_CFLAGS="-arch i386 -I"`cd ../palm-i386/include/; pwd`
> CURL_LIBS=-L`cd ../palm-i386/lib/; pwd` --disable-curl
> --enable-libcurl

The proper configure line would be:

CFLAGS="-arch i386" \
CURL_CFLAGS="-I`cd ../palm-i386/include/; pwd`" \
CURL_LIBS="-lcurl -L`cd ../palm-i386/lib/; pwd`" \
./configure --disable-curl --enable-libcurl

Note the '-lcurl'; it should work with static linking
but you can also just forget about -L and -l and simply use
CURL_LIBS="/path/to/libcurl.a"
or maybe even
CURL_LIBS="-static /path/to/libcurl.a"

Note that libcurl.a itself [probably] depends on other libraries that
you need to add as well; these vary depending on curl configure options.
see the line 'Libs.private:' in the file curl-source-dir/libcurl.pc

> then just ran make and got the following error:
> 
> gcc -DHAVE_CONFIG_H -I. -I../src -I./../src
> -I/Users/hborders/xcode-workspaces/personal/pdk-samples/simple/mac/palm-i386/include
> -Wall -Wall -arch i386 -MT oauthexample-oauthexample.o -MD -MP -MF
> .deps/oauthexample-oauthexample.Tpo -c -o oauthexample-oauthexample.o
> `test -f 'oauthexample.c' || echo './'`oauthexample.c
> mv -f .deps/oauthexample-oauthexample.Tpo .deps/oauthexample-oauthexample.Po
> /bin/sh ../libtool --tag=CC   --mode=link gcc -Wall -Wall -arch i386
> -L/Users/hborders/xcode-workspaces/personal/pdk-samples/simple/mac/palm-i386/lib
> -o oauthexample oauthexample-oauthexample.o ../src/liboauth.la -lssl
> libtool: link: gcc -Wall -Wall -arch i386 -o oauthexample
> oauthexample-oauthexample.o
> -L/Users/hborders/xcode-workspaces/personal/pdk-samples/simple/mac/palm-i386/lib
> ../src/.libs/liboauth.a -lm -lcrypto -lssl
> Undefined symbols:

[..snip..]

> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make[1]: *** [oauthexample] Error 1
> make: *** [all-recursive] Error 1
> 
> I have libcurl.a in
> /Users/hborders/xcode-workspaces/personal/pdk-samples/simple/mac/palm-i386/lib.
>  I can see that that directory is listed in the first -L entry, so I
> don't know why it wouldn't be found. 

'man gcc' reads:
 -L  Add directory dir to the list of directories to be searched for -l

You need to add '-lcurl'

> My only guess is that the
> dynamic libs are being searched first in all search path and are
> getting found in /opt/local/lib.  Ideally, I wouldn't even have
> /opt/local/lib/ on the search path.  I'd prefer to both take
> /opt/local/lib off the search path and tell the linker to prefer
> static libs over dylibs.

I don't think this is the case. '-L' paths are searched first.


I suggest to try to compile the example by hand:

cd liboauth-source-dir/tests/
gcc -arch i386 \
-I../src/ \
-I/Users/hborders/xcode-workspaces/personal/pdk-samples/simple/mac/palm-i386/include/
\
/Users/hborders/xcode-workspaces/personal/pdk-samples/simple/mac/palm-i386/lib/libssl.a
\
/Users/hborders/xcode-workspaces/personal/pdk-samples/simple/mac/palm-i386/lib/libcurl.a
\
../src/.libs/liboauth.a \
-o oauthexample oauthexample.c

You'll need to add a couple off other .a files (dependencies of libssl
and libcurl) and then work backwards to find out the correct ./configure
flags.

Anyway you'll need to do that again when you statically link your
application; so this exercise will be useful later on.

On OSX you can use 'otool -l ' to find out the libraries an
executable or .dylib depends on; other unix-systems use 'ldd' for that.


and somewhat off-topic:
I dunno if it will be an option for the final target-platform
'cortex-a8', but a much easier way than static linking would be to use
.dylibs and simply ship those with your application (OSX does that per
default): use 'install_name_tool' to modify your executable to tell it
where the .dylibs are found. You also need to modify the shipped .dylibs
with said tool to "tell them" where dependand .dylibs are found.
..using a wrapper-script to start your app with LD_PRELOAD or
LD_LIBRARY_PATH environment variables may also be an option.


> If this is too noobish, please understand tha

Re: [oauth] Compiler Error on Mac OSX 10.6.3

[Robin Gareus]

Hi Heath,

Oh. libc, libm, and libpthread is very minimalistic. You may need libz
for OpenSSL. I don't know how easy it is these days to get OpenSSL or
NSS x-compiled. I only remember that it took me a while to figure out
how to x-compile OpenSSL with MinGW a few years ago..

If you stumble over portable MIT/X11 licensed code for calculating
RSA-SHA1 and HMAC-SHA1 signatures, I'll be happy to plug that into
src/hash.c. Using NSS or OpenSSL is a bit overkill.

There's no other dependency; curl or libcurl is optional; but I dare say
you want to have it because it's a very convenient way perform HTTP(s)
requests. According to http://curl.haxx.se/docs/companies.html it is
available on Palm.

As for static libs, you may know that you can use
'./configure --enable-static --disable-shared'

Let me know how it goes. good luck,
robin

On 06/01/2010 03:42 PM, Heath Borders wrote:
> Thanks!
> 
> I'm eventually trying to build this for my palm pre, which has only
> libc, libm, and libpthread available.  So, I'm having to build all
> dependencies as static libs.  I'm just starting with i386 because the
> pre simulation libs are in i386.  Eventually, everything will have to
> be compiled for cortex-a8.
> 
> 
> 
> -Heath Borders
> hbord...@mail.win.org
> Twitter: heathborders
> http://heath-tech.blogspot.com
> 

-- 
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oa...@googlegroups.com.
To unsubscribe from this group, send email to 
oauth+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/oauth?hl=en.

Re: [oauth] Compiler Error on Mac OSX 10.6.3

[Robin Gareus]

On 05/31/2010 03:10 AM, Robin Gareus wrote:
> On 05/31/2010 01:31 AM, Heath wrote:
>> I ran configure with --prefix=`pwd` (I'm trying to embed oauth onto my
>> palm pre, and I didn't want to add it to my general system yet) and I
>> got the following compiler error on Mac OSX 10.6.3:
>>
>> mcheath:liboauth-0.8.5 hborders$ make
>> Making all in src
>> make  all-am
>> /bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -
>> I.-Wall  -g -O2 -MT liboauth_la-oauth.lo -MD -MP -MF .deps/
>> liboauth_la-oauth.Tpo -c -o liboauth_la-oauth.lo `test -f 'oauth.c' ||
>> echo './'`oauth.c
>> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -Wall -g -O2 -MT
>> liboauth_la-oauth.lo -MD -MP -MF .deps/liboauth_la-oauth.Tpo -c
>> oauth.c  -fno-common -DPIC -o .libs/liboauth_la-oauth.o
>> In file included from oauth.c:43:
>> xmalloc.h:12: error: expected declaration specifiers or ‘...’ before
>> numeric constant
>> xmalloc.h:12: error: expected declaration specifiers or ‘...’ before
>> ‘__builtin_object_size’
>> xmalloc.h:12: warning: conflicting types for built-in function
>> ‘__builtin___snprintf_chk’
>> make[2]: *** [liboauth_la-oauth.lo] Error 1
>> make[1]: *** [all] Error 2
>> make: *** [all-recursive] Error 1
>>
>> I commented out line 12 in xmalloc.h and everything compiled fine.
>>
>> Is this a bug?  Is this even the right place to post this issue?
> not really and yes.
> 
> It's some incompatibility between Xcode and POSIX-C99.
> I'll have a look to resolve the issue. Thanks for reporting this.

OK, the problem got resolved in liboauth-0.8.6.

I ran into a minor issue, OSX does not provide pkgconfig files for it's
curl library.

CURL_CFLAGS="-I/usr/include/curl" CURL_LIBS="-lcurl" \
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig/ \
./configure

or alternatively './configure --disable-libcurl' work fine.

FWIW: a universal-dylib can be compiled with:

CFLAGS="-arch i386 -arch ppc -arch x86_64" \
CURL_CFLAGS="-I/usr/include/curl" CURL_LIBS="-lcurl" \
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig/ \
./configure --disable-dependency-tracking


> Cheers!
> robin
> 
>> Thanks.
>> -Heath
>>
> 

-- 
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oa...@googlegroups.com.
To unsubscribe from this group, send email to 
oauth+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/oauth?hl=en.

Re: [64studio-devel] snd-hrtimer

[Robin Gareus]

On 11/07/2009 03:21 PM, Ralf Mardorf wrote:
> Hi :)
> [..]
> Someone on LAD asked what timer preferred to use for sequencing. Because 
> of this happy coincidence I found out, that for the default 64 Studio 
> 3.0-beta3 kernel the module snd-hrtimer isn't loaded and in addition 
> that there isn't such a module.
> 
> Okay, because of ...
> 
> $ cat /boot/config-2.6.29-1-multimedia-amd64 | grep HRTIMER
> # CONFIG_SND_HRTIMER is not set
> 

Late follow up.. there's currently some discussion on LAU:

quoting
http://lists.linuxaudio.org/pipermail/linux-audio-user/2010-May/069902.html

>> In a different thread you mention, regarding jackd's use of snd-seq:
>> the timing behaviour of the two -X options (seq and raw) are not very
>> good. some might be sufficiently uncharitable as to call them
>> unusable".
>>
>> Would using snd-hrtimer with snd-seq change this assessment?
>
> No, they are just badly designed and implemented from this
> perspective. They both have substantial jitter built into their
> design.

___
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel

Re: [64studio-users] [64studio-devel] snd-hrtimer

[Robin Gareus]

On 11/07/2009 03:21 PM, Ralf Mardorf wrote:
> Hi :)
> [..]
> Someone on LAD asked what timer preferred to use for sequencing. Because 
> of this happy coincidence I found out, that for the default 64 Studio 
> 3.0-beta3 kernel the module snd-hrtimer isn't loaded and in addition 
> that there isn't such a module.
> 
> Okay, because of ...
> 
> $ cat /boot/config-2.6.29-1-multimedia-amd64 | grep HRTIMER
> # CONFIG_SND_HRTIMER is not set
> 

Late follow up.. there's currently some discussion on LAU:

quoting
http://lists.linuxaudio.org/pipermail/linux-audio-user/2010-May/069902.html

>> In a different thread you mention, regarding jackd's use of snd-seq:
>> the timing behaviour of the two -X options (seq and raw) are not very
>> good. some might be sufficiently uncharitable as to call them
>> unusable".
>>
>> Would using snd-hrtimer with snd-seq change this assessment?
>
> No, they are just badly designed and implemented from this
> perspective. They both have substantial jitter built into their
> design.

___
64studio-users mailing list
64studio-users@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-users

Re: [oauth] Compiler Error on Mac OSX 10.6.3

[Robin Gareus]

On 05/31/2010 01:31 AM, Heath wrote:
> I ran configure with --prefix=`pwd` (I'm trying to embed oauth onto my
> palm pre, and I didn't want to add it to my general system yet) and I
> got the following compiler error on Mac OSX 10.6.3:
> 
> mcheath:liboauth-0.8.5 hborders$ make
> Making all in src
> make  all-am
> /bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -
> I.-Wall  -g -O2 -MT liboauth_la-oauth.lo -MD -MP -MF .deps/
> liboauth_la-oauth.Tpo -c -o liboauth_la-oauth.lo `test -f 'oauth.c' ||
> echo './'`oauth.c
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -Wall -g -O2 -MT
> liboauth_la-oauth.lo -MD -MP -MF .deps/liboauth_la-oauth.Tpo -c
> oauth.c  -fno-common -DPIC -o .libs/liboauth_la-oauth.o
> In file included from oauth.c:43:
> xmalloc.h:12: error: expected declaration specifiers or ‘...’ before
> numeric constant
> xmalloc.h:12: error: expected declaration specifiers or ‘...’ before
> ‘__builtin_object_size’
> xmalloc.h:12: warning: conflicting types for built-in function
> ‘__builtin___snprintf_chk’
> make[2]: *** [liboauth_la-oauth.lo] Error 1
> make[1]: *** [all] Error 2
> make: *** [all-recursive] Error 1
> 
> I commented out line 12 in xmalloc.h and everything compiled fine.
> 
> Is this a bug?  Is this even the right place to post this issue?
not really and yes.

It's some incompatibility between Xcode and POSIX-C99.
I'll have a look to resolve the issue. Thanks for reporting this.

Cheers!
robin

> Thanks.
> -Heath
> 

-- 
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oa...@googlegroups.com.
To unsubscribe from this group, send email to 
oauth+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/oauth?hl=en.

Re: [LAD] [LAU] like "qjackctl", but trimmed of all fat

[Robin Gareus]

Hi Julien, Hey Aaron,

read 'jack_lsp --help'.

'-t' does not take any arguments; it just makes jack_lsp print the type.
the filter-string only acts on the port-name (BTW, not only the
beginning of the port-name; but it's case-sensitive: strstr() )

Anyway I can reproduce the problem, some jack-midi ports show up in the
audio-tab of jackctl20100528b.py.

jackctl20100528b checks for lowercase 'midi' in the port-name instead of
looking up the port-type. So a2jmidi for example with an upper-case M
"Midi.." ends up in the audio-panel.

Your suggestion to parse the output of 'jack_lsp -t -c' is spot on.
the (currently 2) possible return values are (indented by tab):

#define JACK_DEFAULT_AUDIO_TYPE "32 bit float mono audio"
#define JACK_DEFAULT_MIDI_TYPE "8 bit raw midi"

..or as you suggest using the python-module for JACK may also simplify
things and make jackctl easier to maintain.

Cheers!
robin

PS. Oh, and which of qjackctl's features makes it 'fat'? it's not
bloated in any way. I'd rather put it the other way 'round and say that
jackctl is 'slim'. Sorry could not resist.


On 05/29/2010 12:23 PM, Julien Claassen wrote:
> Hello Aaron and Jack-Team!
>   There seems to be a bug in my jack_lsp. I just started a2jmidid and
> j2amidi_bridge. when I do a jack_lsp I get all the ports.
>   When I do: jack_lsp -t midi I only get one port from jack_midi_clock,
> but none of the other ones.
>   When I type: jack_lsp -t, I can't see a difference between the
> jack_midi_clock port and the others:
> jack_lsp -t
> [...]
> a2j:Virtual Raw MIDI 0-0 [16] (capture): VirMIDI 0-0
> 8 bit raw midi
> a2j:Virtual Raw MIDI 0-0 [16] (playback): VirMIDI 0-0
> 8 bit raw midi
> a2j:Virtual Raw MIDI 0-1 [17] (capture): VirMIDI 0-1
> 8 bit raw midi
> a2j:Virtual Raw MIDI 0-1 [17] (playback): VirMIDI 0-1
> 8 bit raw midi
> a2j:Virtual Raw MIDI 0-2 [18] (capture): VirMIDI 0-2
> 8 bit raw midi
> a2j:Virtual Raw MIDI 0-2 [18] (playback): VirMIDI 0-2
> 8 bit raw midi
> a2j:Virtual Raw MIDI 0-3 [19] (capture): VirMIDI 0-3
> 8 bit raw midi
> a2j:Virtual Raw MIDI 0-3 [19] (playback): VirMIDI 0-3
> 8 bit raw midi
> a2j:M Audio Delta 1010LT [20] (capture): M Audio Delta 1010LT MIDI
> 8 bit raw midi
> a2j:M Audio Delta 1010LT [20] (playback): M Audio Delta 1010LT MIDI
> 8 bit raw midi
> j2a_bridge:playback
> 8 bit raw midi
> a2j:j2a_bridge [129] (capture): capture
> 8 bit raw midi
> Jack MIDI Clock:midi_out
> 8 bit raw midi
> 
>   Or is the argument "midi" only seen as the start of a port_name?
>   If so, Aaron, you must rewrite this part of jackctl (I guess you do
> what I described, because I get exactly your output). You should rewrite
> it using:
> jack_lsp -t
>   And then parse the type info underneath each name. I think a simple
> grabbing for "audio" or "midi" will do. But I guess, that in the long
> run, using the python module for jack, will be more efficient and easy
> to use.
>   Kindly yours
>   Julien
> 
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[oauth] [ANN] liboauth 0.8.5 is out.

[Robin Gareus]

Hi OAuthers,

I'm proud to announce a new revision of liboauth - the C library.

The most prominent change is the that NSS can be used instead of OpenSSL
as alternate cryptographic backend. The motivation for this was that
OpenSSL may pose an issues with GPL licensed code (see README).

There's been a variety of minor updates: configurable cURL timeout
(thanks to Emil A Eklund), example-code for using HTTP Authorization
header, MIT-licensed xmalloc,.. see the Changelog for details.

Veracode.com has reviewed liboauth and assigned it an 'A+' aka "AL4 High
Assurance Level". Their main reason for not granting 'AAA' was that
liboauth used POSIX-rand() for generating the NONCE. It's extremely
unlikely that this could be used for an exploit or DOS but anyway:
since 0.7.2, NSS or OpenSSL rand() implementations are used if
available. Veracode is currently re-evaluating; I've been putting this
announcement off until I get a reply; but they're too busy at the moment
and I did not pay them to do it.


liboauth documentation, source-tgz and examples are available at
  http://liboauth.sourceforge.net/

The source-code is accessible via SVN from
  https://liboauth.svn.sourceforge.net/svnroot/liboauth/trunk
and mirrored at
  https://oauth.googlecode.com/svn/code/c/liboauth

Bilal Akhtar has stepped forward and packaged liboauth for Debian.
He and Paul Wise have been particularly helpful identifying and
suggesting fixes for lintian warnings (typos in man-page & doc,
exported-symbol control, missing libtool macros and licensing issues).
It should be available in Debian soon.

have fun,
robin

PS. moving along with OAuth 2.0, liboauth2 is in the making. Looks like
it's gonna be easier an easier job :-) If you'd like to get involved
please contact me.

-- 
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oa...@googlegroups.com.
To unsubscribe from this group, send email to 
oauth+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/oauth?hl=en.

Re: [oauth] Problems using liboauth in Qt project

[Robin Gareus]

On 05/27/2010 09:52 AM, Miko Kiiski wrote:
> Hi Olivier!
> 
> Seems like you are right about that. I was under the impression that I would
> not have to do anything special to use the C libraries in C++, but seems
> that some externs are needed. Do you think putting the '#include '
> inside 'extern "C" {}' would solve the problem? Need I do more?

no, a 'simple'

extern "C" {
  #include "oauth.c"
}

will do the trick. The functions using liboauth's API do not need to be
declared extern "C".

HTH,
robin

> 2010/5/27 Olivier Berger 
> 
>> Hi.
>>
>> Le mercredi 26 mai 2010 à 15:00 -0700, elysion a écrit :
>>> Hi!
>>>
>>> In the source file I have included the sources in oauthexample.c. When
>>> I try to compile the project with "qmake && make", I get the following
>>> error from the linker:
>>>
>>> g++ -c -pipe -O2 -I/usr/local/include -Wall -W -D_REENTRANT -
>>> DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -
>>> DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/
>>> QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/
>>> include/qt4/QtXml -I/usr/include/qt4 -I. -I. -o moc_mainwindow.o
>>> moc_mainwindow.cpp
>>
>> I'm not sure, but looks like you're trying to mix C and C++ which may
>> require some additional cautions ?
>>
>> It's been a long time I haven't touched C++ so maybe I'm completely OT,
>> though.
>>
>> Just my 2 cents,
>> --
>> Olivier BERGER 
>> http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
>> Ingénieur Recherche - Dept INF
>> Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)
>>

-- 
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oa...@googlegroups.com.
To unsubscribe from this group, send email to 
oauth+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/oauth?hl=en.

Re: [LAD] A little quiz about audio measurements...

[Robin Gareus]

On 05/28/2010 05:34 PM, f...@kokkinizita.net wrote:
> On Fri, May 28, 2010 at 05:05:19PM +0200, Robin Gareus wrote:
> 
>> Well, interpreting an 'experiment' that one has not conducted
>> him/herself without knowing _all_ parameters of the setup is not
>> something to encourage doing..
> 
>> Did you use symmetric (XLR) connections?
> 
> Where possible, yes. Note that we are seeing a *modulation*
> effect, the level of the spurious signals is proportional
> to the wanted signal. It's not additive.

a 2nd measurement showing a measurement at - let's say 1215Hz would have
made that clear in the first place. Anyway I take your word for it.

Thanks for /organizing/ this little quiz; it's quite fun!

>> Are the sample-rate settings of both cards identical?
> 
> Shouldn't matter, as the connection is via an analog signal.
> 
>> what was the physical distance between the devices
>> (cross-talk)?
> 
> It's absolutely not crosstalk.
> 
>> Was there any ground-lift equipment (built-in?) in place
>> or maybe you simply forgot to switch off phantom-power?
>  
> All those would create additive effects, which is not what
> we see. Phantom power, where available, was off. 

good; those charge-pumps that are used to create 48V from 5 or 12V
often cause ripples in the supply voltage.. which in turn can influence
the oscillator.. resulting in signal modulation.

> Card X
> has both line and mic inputs, all show the same result.
> Mic inputs are driven via a balanced passive attenuator
> with an output impedance of 50 ohm.
> 
>> Anyway, good that you've labeled it 'quiz'; so here's my guess:
>>
>> You're encountering reflections (or even standing-waves) in the cable.
>> (did you uncoil it? or was it a very short one?)
>> Did you repeat the measurement? using different cables for example.
> 
> No differnece seen between a cable of 3 m and on of 18 m.
> 
> This will answer most other posters, except Chris:
> 
>> Why 1015 Hz ?
> 
> To clearly separate the signal from any 50 Hz harmonics.
> 
> 
> One more hint: card X is a very high end one. It should
> be 'perfect', or at least much better than card A.

OT: I would not trust any consumer-grade audio-interface for signal
differences larger than 80dB anyway. I'm amazed that card A shows such a
low noise-floor in the loop-back test.

> Ciao,
> 
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] A little quiz about audio measurements...

[Robin Gareus]

On 05/28/2010 05:05 PM, Robin Gareus wrote:
> On 05/28/2010 02:31 PM, f...@kokkinizita.net wrote:
>> Hello all,
>>
>> This week I had to perform measurements on a audio
>> interface, and this resulted in some quite interesting
>> results. Before revealing what happened, I'll let you
>> have a look at some of the data and come up with your
>> own conclusions, see
>>
>> <http://www.kokkinizita.net/linuxaudio/quiz.html>
>>
>> (Free beer at the next LAC for the best analysis)
>>
>> Ciao,
>>
> 
> Well, interpreting an 'experiment' that one has not conducted
> him/herself without knowing _all_ parameters of the setup is not
> something to encourage doing..
> 
> Did you use symmetric (XLR) connections? Are the sample-rate settings of
> both cards identical? what was the physical distance between the devices
> (cross-talk)? Was there any ground-lift equipment (built-in?) in place
> or maybe you simply forgot to switch off phantom-power?
> 
> Anyway, good that you've labeled it 'quiz'; so here's my guess:
> 
> You're encountering reflections (or even standing-waves) in the cable.
> (did you uncoil it? or was it a very short one?)

on 2nd thought (just been on the toilet) those could be in the order of
-75db but they would not yield a symmetric spectrum as you presented.

Sorry for the noise :)
robin

> Did you repeat the measurement? using different cables for example.
> 
> Cheers!
> robin
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] A little quiz about audio measurements...

[Robin Gareus]

On 05/28/2010 05:05 PM, Ralf Mardorf wrote:
> Chris Cannam wrote:
>> Why 1015 Hz?
> 
> Slew rate of card x's input op-amps?

Slew-rates of op-amps are higher by at least an order of magnitude:
off-the shelf cheap op-amps have ~ 10V/us. Fons' test signal may be
~50mV peak-to peak.
In reply to Olivier message Fons already stated that it's not an issue
with sampling. Besides there's usually a low-pass filter on each analog
input.

He probably choose 1015 Hz for aliasing: 48000/1015 or 44100/1015 is not
a common ratio. ~1000 Hz is also in the middle of the card's spectrum
and there's rarely sth. around your house that oscillates at frequency.

There may be more to it, though. Fons?
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] A little quiz about audio measurements...

[Robin Gareus]

On 05/28/2010 02:31 PM, f...@kokkinizita.net wrote:
> Hello all,
> 
> This week I had to perform measurements on a audio
> interface, and this resulted in some quite interesting
> results. Before revealing what happened, I'll let you
> have a look at some of the data and come up with your
> own conclusions, see
> 
> 
> 
> (Free beer at the next LAC for the best analysis)
> 
> Ciao,
> 

Well, interpreting an 'experiment' that one has not conducted
him/herself without knowing _all_ parameters of the setup is not
something to encourage doing..

Did you use symmetric (XLR) connections? Are the sample-rate settings of
both cards identical? what was the physical distance between the devices
(cross-talk)? Was there any ground-lift equipment (built-in?) in place
or maybe you simply forgot to switch off phantom-power?

Anyway, good that you've labeled it 'quiz'; so here's my guess:

You're encountering reflections (or even standing-waves) in the cable.
(did you uncoil it? or was it a very short one?)

Did you repeat the measurement? using different cables for example.

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Announcing: ecaedl.pl Edit Decision List Capable Audio Playing

[Robin Gareus]

drew Roberts wrote:
> On Tuesday 25 May 2010 12:10:26 you wrote:
>> drew Roberts wrote:
>>> I have been looking for an EDL capable audio player for a while now but
>>> have not found one.
>> I don't think there's an open-source audio player that does.
>> Mplayer has support for EDL but is using it's own homebrew EDL format;
>>
>> May I ask what you are trying to accomplish?
> 
> Sure. and the answer will make much of the complexity below go away for my 
> use 
> case.
> 
> I listen to some podcasts that I think it would be useful for some other 
> folks 
> to listen to as well but people being people, and these people being busy to 
> boot, they never seem to get around to listening.
> 
> Most of the podcasts are about an hour long.
> 
> What I want to do is listen to the podcasts, mark up an edl to pull out the 
> parts I think might be most interesting to them and also encourage them to 
> listen to the whole thing.

I guess the easiest would be to just use http://soundcloud.com/
You can add comments on the time-line, tag regions and easily share.
see http://soundcloud.com/search?q[fulltext]=podcast for an example.

OTOH, this is not a solution worthy of being mentioned on LAD.

> I would like to give them a link to the podcast and the edl file and let them 
> play the audiofile controlled by the edl.

You'll want to use SMIL for that: http://www.w3.org/AudioVideo/

As for creating the SMIL-EDL; that'll be the biggest problem..
Making a SMIL template is a one-time job, but finding a good
audio-player to generate your in/out timecode is an issue. I don't know
if there's a dedicated app for that. Maybe audacity or ardour's
cue-files files can be used as a basis.

I'm pretty sure there'll be a few projects in the not too distant
futures doing this with webm + HTML5.

> So, for what I want, the audio playback does not need to be gapless and nor 
> does it need to be accurate to less than a few seconds.
> 
> Naturally I can see the usefulness of those abilities for other uses.
>>> So I hacked together ecaedl.pl which work but is very rough.
>>>
>>> More info here:
>>>
>>> http://zotzbro.blogspot.com/2010/05/edl-edit-decision-list-audio-player.h
>>> tml
>> thanks for sharing.
>>
>>> pastebin link here:
>>>
>>> http://pastebin.com/esXJwv84
>> A while ago I went down a very similar road:
>> http://rg42.org/gitweb/?p=sodankyla.git;a=blob;f=scripts/vsession.pl
>> parses EDL (CMX, CMX3600, Final-Cut-Pro format and 3.0.0) into a sqlite
>> database; which can then be used to generate fi. an ardour session.
> 
> One thing I want to play with is if I can make the edl files with the 
> graphical version of mplayer where I can more easily use the transport 
> control so that I can make the edl files on the first listening pass and cut 
> down on my time investment. Perhaps it would be better for me to make the edl 
> file by hand while listening in another player.
>> The workflow there is offline; meaning there's no real-time playback of
>> the actual EDL.
>> I got a few [filmsound] projects done using these scripts to generate an
>> initial ardour-session where the original sound is synced according to
>> EDL provided by the film (not video) editor, but I did not have the time
>> to go back and clean up the software [yet].
>>
>>> Right now this needs ecaplay from ecasound and perl. mplayer is useful to
>>> create the edl files but they can be created by hand.
>>>
>>> Would any cross playform audio player group be willing to add edl playing
>>> (and creating) functionality to their player? It would make things much
>>> simpler.
>> It's not as easy as it may sound. You'll need to be able to perform
>> reliable sample-accurate seeking over multiple files and play them back
>> without gap.
> 
> As you can see from my particular use case, I anticipate only one audiofile 
> ever. (I can see that for other uses I might want to work with multiple audio 
> files, but not this one.)
>> If you want to support encoded formats (such as mp3) this can become
>> non-trivial very quickly; it can get even worse if the files mentioned
>> in the EDL have different sample-rates (that's very unusual, but hey)
>>
>> I hazard a guess those are basically the reasons why mplayer does not
>> support EDL for audio. mplayer's playlist & video-EDL feature allows you
>> to mix all kind of codecs/formats: seeking to video-frames (with
>> video-frame accuracy is easier).
>>
>> ciao,
>> robin
> 
> Thanks for the discussion and input.
>>> (I guess I really need to add in a GPL license section to the file...
>>> soonest.
>>>
>>> all the best,
>>>
>>> drew
> 
> drew
> 
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Announcing: ecaedl.pl Edit Decision List Capable Audio Playing

[Robin Gareus]

On May 25, 2010, at 8:02 PM, Niels Mayer wrote:

> What is the particular advantage of EDL, versus something more standard:
> http://www.w3.org/TR/SMIL/
> http://en.wikipedia.org/wiki/Synchronized_Multimedia_Integration_Language ??

"more standard" is relative and depends on the point of view.

EDL (as in formats such as CMX3600) is certainly dated, but still common in 
Film-production (it can be read by a human with a scissor & tape).

Basically that's why I asked about the use-cases or the goal of this 'exercise'.

>From what I can tell about looking at Drew's perl script he's not trying to 
>interpret 'classic' EDL; and just used the term to get the idea across. SMIL 
>would certainly be the better option, though it may be overkill as well..

> Mplayer (and thus http://en.wikipedia.org/wiki/K-Multimedia_Player ,
> smplayer, and gnome-mplayer) supports SMIL although the support is
> rudimentary. SMIL and other means of setting clips&playlists is
> available in the flash-based 'jwplayer' http://www.longtailvideo.com
> "Attribution-NonCommercial-ShareAlike 3.0 Unported" ( in action:
> http://nielsmayer.com/xwiki/bin/view/Macros/JWPlayerJSPL_Test and
> http://nielsmayer.com/xwiki/bin/view/Exhibit/NPRpods3 (work in progress) ).
> 
> The other issue w/ doing it "in the player" is how well do the given
> players handle a playlist. Most of them, even if accessing the same
> media in different cue-locations, do not do a very good job with going
> through "clips" with seamless transitions between the clips. However,
> it's readily possible , with a bit of pre-buffering and pre-fetching
> that allows seamless synchronized playback  just a small matter of
> programming...

been there, done that and using libsndfile this just works and is pretty 
straight-forward.

However other decoder libraries are not very predictable when it comes to 
accurate seeking.
In particular ffmpeg's av_seek_frame() and libqt's  
quicktime_set_audio_position() are not very precise.
The only reliable way to do this correctly with said libs would be to always 
start decoding from the beginning or to stick to a limited set of codecs. OTOH 
you may or may not care about +-1920 audio-samples.

> (i waste way too much time abusing my own software for
> unintended purpose -- "internet sampler and looper"
> --http://nielsmayer.com/ts-episode-timeline.png  )
> 
> Niels
> http://nielsmayer.com
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Announcing: ecaedl.pl Edit Decision List Capable Audio Playing

[Robin Gareus]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

drew Roberts wrote:
> I have been looking for an EDL capable audio player for a while now but have 
> not found one.

I don't think there's an open-source audio player that does.
Mplayer has support for EDL but is using it's own homebrew EDL format;

May I ask what you are trying to accomplish?

> So I hacked together ecaedl.pl which work but is very rough.
> 
> More info here:
> 
> http://zotzbro.blogspot.com/2010/05/edl-edit-decision-list-audio-player.html

thanks for sharing.

> pastebin link here:
> 
> http://pastebin.com/esXJwv84

A while ago I went down a very similar road:
http://rg42.org/gitweb/?p=sodankyla.git;a=blob;f=scripts/vsession.pl
parses EDL (CMX, CMX3600, Final-Cut-Pro format and 3.0.0) into a sqlite
database; which can then be used to generate fi. an ardour session.

The workflow there is offline; meaning there's no real-time playback of
the actual EDL.
I got a few [filmsound] projects done using these scripts to generate an
initial ardour-session where the original sound is synced according to
EDL provided by the film (not video) editor, but I did not have the time
to go back and clean up the software [yet].

> Right now this needs ecaplay from ecasound and perl. mplayer is useful to 
> create the edl files but they can be created by hand.
>
> Would any cross playform audio player group be willing to add edl playing 
> (and 
> creating) functionality to their player? It would make things much simpler.

It's not as easy as it may sound. You'll need to be able to perform
reliable sample-accurate seeking over multiple files and play them back
without gap.

If you want to support encoded formats (such as mp3) this can become
non-trivial very quickly; it can get even worse if the files mentioned
in the EDL have different sample-rates (that's very unusual, but hey)

I hazard a guess those are basically the reasons why mplayer does not
support EDL for audio. mplayer's playlist & video-EDL feature allows you
to mix all kind of codecs/formats: seeking to video-frames (with
video-frame accuracy is easier).

ciao,
robin

> (I guess I really need to add in a GPL license section to the file... soonest.
> 
> all the best,
> 
> drew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkv79nIACgkQeVUk8U+VK0K02wCdF9iJxrbn2uEFE1vIkLSh7PTB
UMgAn3Y/XpGfSs2itL0RFLwsOvjLU2nD
=ze1n
-END PGP SIGNATURE-
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: RFS: liboauth (Updated package)

[Robin Gareus]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Paul Wise wrote:

>>> How are you building the manual page? Your Makefile.am doesn't list
>>> any commands for doing so.
>> The top-level Makefile.am contains:
>>
>> stamp-doxygen: src/oauth.h doc/mainpage.dox
>>  $(DOXYGEN) Doxyfile && touch stamp-doxygen
>>  cp doc/man/man3/oauth.h.3 doc/oauth.3
> 
> Aha, well you could add a sed command to the end of that.

There are a lot of hypens that should not be replaced: doxygen escapes
it correctly in the title and minus-signs are used in numeric [troff]
expressions (fi. '.ti -1c') or font-size adjustments (s-1); besides it's
correct in most cases: They're hyphens not a minus-signs.

A simple 's/-/\\-/g' would make things worse.

Turning the code from /usr/share/lintian/checks/manpage into a sed
regexp is not something to be done on a lazy Sunday afternoon.

However I came up with a pragmatic regexp that fixes liboauth's man
page. liboauth-0.8.5 is up.

Thanks for all the comments, I learned quite a few new details.
Cheers!
robin

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkv5RvMACgkQeVUk8U+VK0J+ZwCeIOxTmZ6Cgprz3x3labnYLWOV
+3YAnRTnyozlonxU8IiYKbc0GHRAVzX6
=nLlB
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bf946f3.30...@gareus.org

Re: RFS: liboauth (Updated package)

[Robin Gareus]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Paul Wise wrote:
> [CCing you since I presume you aren't subscribed, apologies if you are]
No I'm not. Thanks for paying attention.

> On Fri, May 21, 2010 at 1:17 AM, Robin Gareus  wrote:
> 
>>> xmalloc is GPL not LGPL so I'm wondering why upstream and
>>> debian/copyright refer to the LGPL.
>> xmalloc is 'generated' by autotools (autotools replaces the project-name in
>> there) and /usr/share/doc/autoproject/README reads:
>>
>> "autoproject itself is distributed under the GNU General Public License.
>> As a special exception to the GNU General Public License, you may
>> use the files generated by autoproject without any restriction."
> 
> Hmm. I'd say that exception is so vague as to be useless. A permissive
> license would be much better.

I've contacted the autotools author and suggested to change that
sentence in the README to:
"..without any restriction unless the generated-file states otherwise."

Getting the FSF to change the license of xmalloc.c to something more
permissive would be great; but I'm not prepared to fight that uphill
battle any longer :) I usually like the GPL and it's easy enough to
re-invent xmalloc, anyway.

>>> xmalloc reduces the amount of software that can link with liboauth
>>> (due to GPL licensing incompatibilities), it would be nice if upstream
>>> could use plain malloc. You may want to send upstream a patch.
>> no need to send a patch:
>> xmalloc is only used IFF liboauth is configured with --enable-gpl.
> 
> Ah. The README says that --disable-gpl may cause segfaults, that
> doesn't sound good.

Well, in practice it does not make much of a difference if the program
exit(1) or segfaults if it encounters an out-of-memory error, does it :)

Anyway I figured it's easier to just replace GPL-xmalloc with some
equivalent.. done in >= liboauth 0.8.0.

> Also, by using OpenSSL, you are preventing GPLed apps from using
> liboauth due to license incompatibility between the apps and OpenSSL,
> yay transitive license violations :D
> 
> http://lists.debian.org/debian-legal/2007/11/msg00061.html
> 
> Providing GnuTLS and or NSS backends might be one option to fix this.
> Another might be to delegate SSL stuff to the app using liboauth.

Since liboauth-0.7.2 '--enable-nss' is available which makes liboauth
use NSS instead of OpenSSL.

> Also, in 0.7.1, xmalloc is still linked into the library, you need to
> do some ifdefs in src/Makefile.am.

Thanks for the hint; so far I was under the impression that simply not
using the code (#ifdefs in xmalloc.h/xmalloc.c) would do the trick.

> libtool: link: x86_64-linux-gnu-gcc -shared  .libs/liboauth_la-oauth.o
> .libs/liboauth_la-hash.o .libs/liboauth_la-xmalloc.o
> .libs/liboauth_la-oauth_http.o   -lm -lcrypto /usr/lib/libcurl.so
> -Wl,-z -Wl,defs   -Wl,-soname -Wl,liboauth.so.0 -o
> .libs/liboauth.so.0.5.2

water under the bridge now.

>>> Uhh, actually since you are linking xmalloc and OpenSSL (GPL & OpenSSL
>>> licenses are not compatible), the liboath0 binary package is not
>>> distributable!
>> Thanks for bringing this to my attention, I've added an exemption as 
>> suggested
>> by http://lists.debian.org/debian-legal/2004/05/msg00595.htm
> 
> Uh, you are not the copyright holder of the xmalloc code, so you cannot do 
> this.
> 
> As said above, --disable-gpl and dropping OpenSSL is the solution here.

since 0.8.0 there's no GPLed code in liboauth anymore.

The packaging (debian/ folder in the source-repo) is still GPL; but
that's mostly for my own convenience and once you're done I'm happy to
remove it from the source (unless you suggest otherwise).

>>> libtoolize: rerunning libtoolize, to keep the correct libtool macros 
>>> in-tree.
>>> libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
>> ?? I don't use ACLOCAL_AMFLAGS in Makefile.am.
> 
> Probably it is prompting you to add it.

No, but I've added it anyway (liboauth-0.8.3).

>>> lintian complaints (send most upstream):
> 
>>> X: liboauth0: shlib-calls-exit usr/lib/liboauth.so.0.5.2
> 
> Looks like that was caused by using xmalloc.
> 
>>> I: liboauth-dev: hyphen-used-as-minus-sign usr/share/man/man3/oauth.3.gz:374
>>> I: liboauth-dev: hyphen-used-as-minus-sign usr/share/man/man3/oauth.3.gz:376
>>> I: liboauth-dev: hyphen-used-as-minus-sign usr/share/man/man3/oauth.3.gz:403
>>> I: liboauth-dev: hyphen-used-as-minus-sign usr/share/man/man3/oauth.3.gz:405
>>> I: liboauth-dev: hyphen-used-as-minus-sign usr/share/man/man3/oauth.3.gz:863
>> Well, thes

Re: RFS: liboauth

[Robin Gareus]

Bilal Akhtar  yahoo.com> writes:

> 
> 
> > Hi.
> > 
> > Just a minor comment :
> > 
> > Le vendredi 14 mai 2010 à 10:49 +0300, Bilal Akhtar a écrit :
> > 
> > > It builds these binary packages:
> > > liboauth-dev - C library for implementing oAuth 1.0 specification
(development files)
> > > liboauth0  - C library for implementing oAuth 1.0 specification
> > 
> > Why not "OAuth", as usually written in the oauth.net site instead of
> > "oAuth" ?
> 
> Fine, will correct that and upload soon to m.d.n.

Also corrected upstream as of v0.7.1. Thanks for pointing that out; just a habit
of using lowercase for the first letter in camel case :)
 
> > Btw, what applications are using it (I imagine it's not just for the
> > pleasure of packaging a library) ?
> 
> My app is using it (currently under development). This library has the
> distinction of being the only C library that provides OAuth support.
> 
> Cheers,
> Bilal Akhtar.
 
Some other happy users of liboauth are:
 http://github.com/DaveGamble/soundcloud-c-api-wrapper/tree/master
 http://github.com/anandi/libfireeagle/tree/master
 http://maemo.org/downloads/product/OS2008/conboy/
 http://github.com/x42/oauth-utils/tree/master

and there are quite a few more.

best,
robin


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/loom.20100520t193554-...@post.gmane.org

Re: RFS: liboauth (Updated package)

[Robin Gareus]

Paul Wise  debian.org> writes:
> 
> On Thu, May 20, 2010 at 1:52 PM, Bilal Akhtar  yahoo.com>
wrote:
>

Hi there,
Upstream liboauth-developer here.

 
> > in Debian was the reasons why many app developers copied the source code
into their programs.
> 
> Way to get my attention! If any of these apps are already in Debian,
> please notify the security team about the embedded code copies. Since
> you got my attention, here is a review (I don't have time to commit
> ongoing sponsorship, sorry):
> 
> Please send the patches upstream if you haven't already.
> 
> You can replace aclocal/autoheader/autoconf/automake with autoreconf.
> Probably you want dh-autoreconf instead of doing it manually. What is
> the reason for running autotools anyway?
> 
> The paths in debian/patches/acandam.diff are specific to your personal
> machine, that is probably a bad idea.
> 
> debian/patches/changeencodinglocale.diff is not present in
> debian/patches/series so it will not get applied, is that what you
> wanted to do?
> 
> Insert my standard comment about library package descriptions, think
> about the audience for each one. -dev package will be manually
> installed by people developing apps using liboauth and also as part of
> build-depends. liboauth0 should only be installed automatically so it
> doesn't need a verbose description.
> 
> You forgot to build-depend on autoconf/libtool.
> 
> debian/docs should probably be named debian/liboauth-dev.examples
> 
> No need to be so specific with the manual page path, usr/share/man/
> should do it.
> 
> xmalloc is GPL not LGPL so I'm wondering why upstream and
> debian/copyright refer to the LGPL.

xmalloc is 'generated' by autotools (autotools replaces the project-name in
there) and /usr/share/doc/autoproject/README reads:

"autoproject itself is distributed under the GNU General Public License.
As a special exception to the GNU General Public License, you may
use the files generated by autoproject without any restriction."

> 
> xmalloc reduces the amount of software that can link with liboauth
> (due to GPL licensing incompatibilities), it would be nice if upstream
> could use plain malloc. You may want to send upstream a patch.

no need to send a patch: 
xmalloc is only used IFF liboauth is configured with --enable-gpl.
 
> Uhh, actually since you are linking xmalloc and OpenSSL (GPL & OpenSSL
> licenses are not compatible), the liboath0 binary package is not
> distributable!

Thanks for bringing this to my attention, I've added an exemption as suggested
by http://lists.debian.org/debian-legal/2004/05/msg00595.htm
 
> It is best to license debian/ under the same license as upstream so
> that they can make use of your patches etc.
> 
> Should you be depending on locales/locales-all too?
> 
> Do you need to install the static library and .la file? Debian seems
> to be moving towards not installing either of these.
> 
> autotools warnings (send upstream):
> 
> libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and

Thanks, added in v0.7.0 (r46 in the sf.net SVN repo)

> libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
> libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.

?? I don't use ACLOCAL_AMFLAGS in Makefile.am.
 
> gcc warnings (send upstream):
> 
> oauthbodyhash.c: In function 'main':
> oauthbodyhash.c:65: warning: unused variable 'bh'

Also fixed. Actually that's example code and 'bh' (aka body-hash) is only unused
in the default example (there's some #ifdef in there).
 
> lintian complaints (send most upstream):
> 
> I: liboauth0: no-symbols-control-file usr/lib/liboauth.so.0.5.2
> X: liboauth0: shlib-calls-exit usr/lib/liboauth.so.0.5.2
> I: liboauth-dev: hyphen-used-as-minus-sign usr/share/man/man3/oauth.3.gz:374
> I: liboauth-dev: hyphen-used-as-minus-sign usr/share/man/man3/oauth.3.gz:376
> I: liboauth-dev: hyphen-used-as-minus-sign usr/share/man/man3/oauth.3.gz:403
> I: liboauth-dev: hyphen-used-as-minus-sign usr/share/man/man3/oauth.3.gz:405
> I: liboauth-dev: hyphen-used-as-minus-sign usr/share/man/man3/oauth.3.gz:863

Well, these are tricky! Said man-page is generated by Doxygen. Any ideas how to
tell doxygen to properly escape those hyphens?

I've found
http://www.mail-archive.com/debian-mentors@lists.debian.org/msg39606.html
but replacing them is not really an option since doxygen is also generating html
from the same sources.


> I: liboauth-dev: spelling-error-in-manpage
> usr/share/man/man3/oauth.3.gz paramater parameter
> I: liboauth-dev: spelling-error-in-manpage
> usr/share/man/man3/oauth.3.gz recieve receive
> I: liboauth0: spelling-error-in-binary ./usr/lib/liboauth.so.0.5.2
> environement environment

LOL. I've corrected those.

Cheers!
robin  



> uscan warning:
> 
> pabs  chianamo:~/tmp/liboauth-0.6.3$ uscan
> Use of uninitialized value $2 in split at /usr/bin/uscan line 1503,
>  line 2.
> 
> Seems that can be fixed by adding a slash to the URL.
> 





-- 
To UNSUBSCRIBE, email to 

Re: [LAD] any pointers for RT kernel for ARM?

[Robin Gareus]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

nescivi wrote:
> Hiho,
> 
> I managed to get SuperCollider and JACK running on my IGEP [1], on the pre-
> configured Ubuntu on the SD, but of course the audio is still bumpy.
> 
> So... I'm looking for a RT kernel for this little machine... Anyone have any 
> pointers?

Did you check http://marc.info/?l=linux-rt-users

There's been a few patches floating around there for ARM and
2.6.31.12-rt20  and there's a thread on Beagle with 2.6.33-rt
(apparently some know decompressor bug and a cherry-pick patch.)

> I did find this one: http://beagleboard.org/project/omap-rt-patch/
> but the project doesn't show much recent activity.
> 
> and... I also noticed that JACK didn't want to run with alsa as backend; oss 
> as backend works though (but gives the bumpy sound).

Does ALSA work (without JACK)?

> Anyone willing to share their experiences doing linux audio on ARM processors?
> 
> sincerely,
> Marije
> 
> 
> [1] http://www.igep-platform.com/
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkv0EZMACgkQeVUk8U+VK0K+EwCfbJDonqjRRSc9eOnYVdoqeSFL
TW4AnR8NOn/nJAWVPHbf5zfP/YlN9jsh
=8TiB
-END PGP SIGNATURE-
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] LAC "Tools" round-table wrapup

[Robin Gareus]

Hey Albert,

On May 17, 2010, at 6:30 PM, Albert Graef wrote:

> Hi Robin,
> 
> I can't get to the wiki page linked to in your previous post, so here
> are some hopefully useful remarks.
> 
really? well we had a 30 min outage this afternoon (CEST) but the site's online:
http://wiki.linuxaudio.org/wiki/tools_comparison

> Robin Gareus wrote:
>> In partictular the "multi-rate", "sync" & "async" need clarification.
> 
> - multirate: The ability to deal with synchronous streams of (audio)
> data at different samplerates.
> 
> - sync: synchronous (sample-based) processing at fixed samplerate(s)
> (typically audio and video).
> 
> - async: asynchronous (event-based) processing (typically MIDI, OSC and
> the like).
> 

Thanks a lot. reading it like this makes perfect sense. 

There's two missing (which were mentioned in a follow up email):

 - batch (does it mean app can be called (headless) from a batch script, or 
that the app itself offers batch processing) 
 - embed. means embedded or embeddable?

> Note that we didn't have experts for all the mentioned programs on board
> during the discussion (most notably, the supercollider people were
> absent since they had a session in parallel), so it can't hurt if the
> feature matrix is proofread by as many eyeballs as possible. ;-)

There's already been quite some additions:
http://wiki.linuxaudio.org/doku.php?id=wiki:tools_comparison&do=revisions
In particular: Lua-AV, Snd-RT, CLM and Fluxus have been reviewed.

Someone (84.215.119.162) recently added categories "RT" and "GC" without 
documenting them :/
IMHO real-time makes sense, but I' don't think that "garbage collection" (if 
that's what GC means) belongs in that table.
Anyway, step 2 (next month) includes removing undocumented and superfluous 
information (eg. so far all discussed tools are x-platform).

ciao,
robin


> Albert
> 
> -- 
> Dr. Albert Gr"af
> Dept. of Music-Informatics, University of Mainz, Germany
> Email:  dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de
> WWW:http://www.musikinformatik.uni-mainz.de/ag

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] LAC "Tools" round-table wrapup

[Robin Gareus]

Philipp Überbacher wrote:
> Excerpts from Robin Gareus's message of 2010-05-15 18:07:53 +0200:
>> Hi LADs,
>>
>> Following up on the LAC Tools round-table, I've started a wiki page:
>> http://wiki.linuxaudio.org/wiki/tools_comparison
>>
>> Since I've not taken part in the discussion, I'm missing a few footnotes
>> and explanation for keys in the context (eg. batch, sync). Could you
>> please enlighten me, or just fill in the missing content there.
>>
>> IMHO it'd also make sense to do a 2nd table with orthogonal practical
>> information, for instance:
>>   audio: JACK,ALSA,..
>>   midi: JACK,ALSA,ALSA-seq
>>   audio-file-formats: pcm,mp3,gig,mid,..
>>   control: OSC,TCP,pipe,MMC,..
>>   interop/sync: jack-transport,MTC
>>   plugins (if applicable): LV2,LADSPA,VST,AU,..
>>
>> Come to think of it, those could be integrated in the apps-database as
>> tags for each tool, similar to:
>> http://wiki.linuxaudio.org/apps/categories/jack_transport
>> but let's get the categories/tags straightened out before starting on an
>> implementation and posting it to LAU. What do you think?
>>
>> Cheers!
>> robin
> 
> I've also not taken part and hence don't even know what this is about.
> Can you enlighten me and show me where to read/listen/watch up on it?

nope. I'm looking for the same info :) The table on the wiki page is
based on a spreadsheet that Albert Graef sent me. Neither the
round-table, not the wrap-up session has been recorded.

I know there've been ~15 people (most of which subscribe to LAD)
participating in the round-table and ~50 in the wrap-up session.
anyone please..

In partictular the "multi-rate", "sync" & "async" need clarification.

I assume "multi-rate" means real-time resampling (different sample-rates
in the _same_ session).
Also "batch" is somewhat sloppy. Does it mean batch processing is
available from inside the application or just that the app can be
launched from a batch script?

> The table looks like it could become something useful, but you're right,
> it reminds of the apps.linuxaudio.org db, which could and should be
> expanded.

right, but the tools-overview is a bit different: It does not aim to be
complete and puts focus on well-established frameworks to give an
overview to newcomers:
"I want to do an interactive A/V piece: What software do you recommend?"

The round-table was intended to give developers an opportunity to
position themselves and think about what a given app does best and how
to distinguish one from the other; along the lines:
"We don't need another framework, we need to consolidate existing ones".

best,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] LAC "Tools" round-table wrapup

[Robin Gareus]

Hi LADs,

Following up on the LAC Tools round-table, I've started a wiki page:
http://wiki.linuxaudio.org/wiki/tools_comparison

Since I've not taken part in the discussion, I'm missing a few footnotes
and explanation for keys in the context (eg. batch, sync). Could you
please enlighten me, or just fill in the missing content there.

IMHO it'd also make sense to do a 2nd table with orthogonal practical
information, for instance:
  audio: JACK,ALSA,..
  midi: JACK,ALSA,ALSA-seq
  audio-file-formats: pcm,mp3,gig,mid,..
  control: OSC,TCP,pipe,MMC,..
  interop/sync: jack-transport,MTC
  plugins (if applicable): LV2,LADSPA,VST,AU,..

Come to think of it, those could be integrated in the apps-database as
tags for each tool, similar to:
http://wiki.linuxaudio.org/apps/categories/jack_transport
but let's get the categories/tags straightened out before starting on an
implementation and posting it to LAU. What do you think?

Cheers!
robin


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] LAC 2010 stream recordings...

[Robin Gareus]

Jens M Andreasen wrote:
> On Wed, 2010-05-05 at 18:17 +0200, Jörn Nettingsmeier wrote:
>> the lac2010 presentation recordings are now available at 
>> http://www.linuxproaudio.org/lac2010/ - kudos to faberman for 
>> very-close-to-realtime post-production!
> 
> I suppose that if I in firefox can only see a bit of static green, then
> that means there is something wrong?
> 
> Seg faults in totem.

They play just fine here in totem, vlc, mplayer and firefox (actually
iceweasel) 3.5.8.

but I've not tested all of the recordings.. which video is causing the
problem? All of them?

robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] LAC 2010 stream recordings...

[Robin Gareus]

Jörn Nettingsmeier wrote:
> hi *!
> 
> 
> the lac2010 presentation recordings are now available at
> http://www.linuxproaudio.org/lac2010/ - kudos to faberman for
> very-close-to-realtime post-production!
> 
> let me take the opportunity to thank all stream team people (many of
> them members of the linux video community, who put in many hours of
> volunteer work to cover our beloved little annual meeting)!
> 
> check out their works and websites, join their projects, send them beer!
> 
> christian thäter, germany (http://lumiera.org/)
>  - cam operator, vision mixing
> 
> florian faber, germany
>  - post production, archive, software support, club mate
> 
> frank neumann, germany
>  - cam operator, emcee
> 
> herman robak, norway (http://developer.skolelinux.no/~herman/)
>  - director of photography, cams, vision mixing, hardware
> 
> marc-olivier barre, france (http://marcochapeau.org/)
>  - relay operator
> 
> yours truly, germany (http://stackingdwarves.net)
>  - vision mixing, technical supervisor, relay operator
> 
> raffaella traniello, italy (http://www.g-raffa.eu/,
> http://vimeo.com/raffatraniello)
>  - cam operator
> 
> robin gareus, france (http://gareus.org/)
>  - hardware, setup, technical support
> 
> thijs koerselman, the netherlands (http://www.vauxlab.com)
>  - cam operator
> 
> wouter verwijlen, the netherlands (http://www.wouterverwijlen.nl)
>  - cam operator
> 
> and of course major kudos to marc groenewegen and everyone at hku for a
> great conference!
> 
> best,
> 

For convenience, they're mirrored at
http://lac.linuxaudio.org/2010/recordings/
and are linked from the conference-program for each presentation along
with the slides.

Many thanks and a round of applause for Jörn for pulling this off.

Cheers!
robin


PS. the Website will be updated the next days with the group-picture,
proceedings, audio from the composition-competition, some
workshop-recordings, etc.

If you have blogs, articles or images from LAC2010, we'd be glad to
link-to or include them. Please announce them on the LAU list or send
them directly to l...@linuxaudio.org.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] LAC2010 - tune in..

[Robin Gareus]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,


For all those who could not make it to Utrecht: LAC2010 is just about to
start here.

Live A/V streams are already online - thanks to Joern -at
http://streamer.stackingdwarves.net/

Remote participants are invited to join #lac2010 on irc.freenode.net, to
be able to take part in the discussions, ask questions, and get
technical assistance in case of stream problems...

The Conference Schedule in online at:
http://lac.linuxaudio.org/2010/?page=program

ciao,
robin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkvb2a4ACgkQeVUk8U+VK0JDcACaArfwzRM34VgBpEAqK/DjY/S8
oRYAoIu2HfLRoVAibfkw97/wn0j1Ukui
=qDnY
-END PGP SIGNATURE-
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev