Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

[OT] an ogg vorbis player for Java ME mobile phones?

by Joern Nettingsmeier

hi everyone! i recently got myself a sony ericsson k850i, which is ok phone-wise and as a modem for linux, except that it doesn't know about ogg vorbis. since it provides a java environment, it must be possible to correct that :) does anyone have pointers to open-source ogg vorbis player implementations for java phones? iiuc, the program needs to be a MIDlet (whatever that means), i.e. it can't be a standalone app with a static void main(), but must inherit from some javax.microedition.foo class similar to web applets. thanks, jörn -- jörn nettingsmeier home://germany/45128 essen/lortzingstr. 11/ http://spunk.dnsalias.org phone://+49/201/491621 Kurt is up in Heaven now.

17 years, 9 months

Re: [LAD] Summercode 2008: LASH, pt. 3

by Phil Mendelsohn

Fons Adriaensen said: > It's the same when you > work in a physical studio: you can use any instruments > you want, make any music you want, use all the effects > equipment, but you're not allowed to modify the studio > itself. I'm not going to argue with your point, but I can come up with a number of counter examples of modifying a physical studio during a session! Putting the playback speakers out of phase so that the vocal mic could be placed in a cancellation node in the live room - neat trick, try it! - in order to accomodate a singer who could not wear headphones due to an injury involved pulling the speaker to get to the banana plug. The signal to the amp had to be mono, and it was harder to get to the back of the amp rack... Some of my most fun in the studio (back in the days) was modifying the studio! -- "Nothing is too small to know, and nothing too big to attempt." --Sir William Cornelius Van Horne

17 years, 9 months

[Fwd: Re: Summercode 2008: LASH, pt. 3]

by Juuso Alasuutari

I'm assuming you meant to post this to the list, Paul. In reply to your comment: One of the motives behind jack-dbus is that a JACK control application shouldn't have to be RT capable since it's not processing any realtime-sensitive data anyway. From a technical perspective, could libjack be extended with such a non realtime control API? -------- Original Message -------- Subject: Re: [LAD] Summercode 2008: LASH, pt. 3 Date: Mon, 04 Feb 2008 11:33:44 -0500 From: Paul Davis <paul(a)linuxaudiosystems.com> Reply-To: paul(a)linuxaudiosystems.com Organization: Linux Audio Systems To: Juuso Alasuutari <juuso.alasuutari(a)gmail.com> References: <47A4B4DC.8080306(a)gmail.com> <20080204123036.GJ2670(a)zita2.kokkinizita.net> <47A73ADC.5060207(a)gmail.com> On Mon, 2008-02-04 at 18:18 +0200, Juuso Alasuutari wrote: > That being said, I still do favor D-Bus over OSC. The point is that they are both irrelevant in the context of JACK itself. First you need an API in JACK to control what you want to control. Then you need a JACK-aware application that speaks <your preferred protocol>. When it gets <your preferred message> it invokes the <relevant part> of the JACK API.

17 years, 9 months

Re: [LAD] jack client autoconnection

by Kjetil S. Matheussen

Fons Adriaensen: > > On Mon, Feb 04, 2008 at 03:32:23PM +0100, Fons Adriaensen wrote: > >> Where jack_autoconnect() would use environment variables, >> read .rc files, invoke the Buddha, or consult Paul Davis or >> the oracle of Delphi to find out which ports to use, but >> without requiring any special support from jackd itself. > > The code required is much shorter than the length of this > thread so far, so I take the liberty to post it. > Quickly but not fully tested. > > I would say that your function is a connect-many-ports-at-once function, not an autoconnect function. What I'm thinking is that the jackd program has an extra option called "--autoconnect-ports / -ap", which contains a comma-separated list of port names. If its not supplied, or "--no-autoconnect / -no" is not supplied either, jack_autoconnect(client,num_ports,port); will connect to the physical ports. This requires some modification to jack. But it shouln't be that much of a work. Besides, two other functions are needed as well: int jack_get_num_autoconnect_playback_ports(void); int jack_get_num_autoconnect_record_ports(void);

17 years, 9 months

Re: [LAD] jack client autoconnection

by Kjetil S. Matheussen

Fons Adriaensen: > >> You can be as much of a professional user as you want to. >> It doesn't change the fact that other professionals might >> not want the system to behave like you do. > >Which again means it should be configurable. Absolutely. I think a new function for jack would be better than an environment variable though: int jack_autoconnect_playback (jack_client_t *, int portnum, const char *source_port); int jack_autoconnect_record (jack_client_t *, int portnum, const char *destination_port); The reason is that this API will make it easier for programs to make autoconnection configurabe. Autoconnecting the old way (which includes finding the physical ports and/or checking environment variables for ports to connect to, etc.) is a lot more hassle than just calling the functions above. > BTW, JSB may turn in his grave, but I _do_ like the > sound of sandysth... I still have to go through the > works to understand the algorithm... Thank you very much. :-) I don't understand the algorithm myself, so if someone else understood it, that would be great. I think its quite similar to green noise, which I read about later, created by moore at ucsd if I remember correctly.

17 years, 9 months

Re: [LAD] jack client autoconnection (fwd)

by Kjetil S. Matheussen

Jonatan Liljedahl: >> >> >> Thanks for clearing up. But I'm pretty sure your idea is too >> simple. We also need a way to create ports which are not >> autoconnected. >> >> The ideal way, if we follow this thread of thinking, would >> be to add another type of jack_port_register function, which >> does not autoconnect: >> >> jack_port_register_no_autoconnect(client,...); >> >> However, this new API will break a lot of current programs >> which are using the old jack_port_register function instead. >> Infact I don't think there is any (sane) way to make your >> proposal work without creating lots of mess with ports >> in old programs who are autoconnecting when it shouldn't. > > I think my proposal with a JackPortAutoConnect bit in JackPortFlags is > sane, it would not break old applications; they would continue to > function exactly as they are now. but updated code can get rid of their > own autoconnection and use this autoconnect bit in the flags to > jack_port_register() instead. > Yes, as long as JackPortAutoConnect is false by default, that's definietely a sane solution. Its basically the same kind of proposal I made, just using a flag to jack_port_register instead of a new function. But there is one problem with it: jack_client_t *client=... jack_port_t *out_port[0]=jack_port_register(client,...JackPortAutoConnect); jack_port_t *out_port[1]=jack_port_register(client,...JackPortAutoConnect); <something happens> jack_port_t *new_out_port[0]=jack_port_register(client,...JackPortAutoConnect); jack_port_t *new_out_port[1]=jack_port_register(client,...JackPortAutoConnect); The problem is that new_out_port[0] and new_out_port[1] will connect to physical port number 2 and 3 instead of 0 and 1. How do you fix this problem without adding a new function to jacklib?

17 years, 9 months

ALSA & daemon

by Fons Adriaensen

Is there any reason why raw ALSA MIDI streams would stop working if the process that opened them switches to daemon mode ? (see mand daemon(3)) Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa.

17 years, 9 months

Re: [LAD] [OT] an ogg vorbis player for Java ME mobile phones?

by Joern Nettingsmeier

nick, thanks for your reply - i guess you intended it to go to the list as well? anyway, in case anyone else is interested, Nick Bailey wrote: > http://www.jcraft.com/jorbis/ any use? cool, thanks! it's not java ME, but SE, but i may be able to steal code from it. best, jörn -- jörn nettingsmeier home://germany/45128 essen/lortzingstr. 11/ http://spunk.dnsalias.org phone://+49/201/491621 Kurt is up in Heaven now.

17 years, 9 months

Re: [LAD] Prototyping algorithms and ideas

by Kjetil S. Matheussen

Fons Adriaensen: > >> On Tue, 2008-01-29 at 23:36 +0100, Yann Orlarey wrote: >> >>> A fully functional jack application can be easily generated using the >>> faust2jack command or by pasting the above code in the online faust >>> compiler (http://faust.grame.fr). The performances on my Vaio laptop >>> (Intel Core 2 CPU T7400 @ 2.16GHz) is approximately of 2%. >> >> I think they call that "game, set and match". > > Not really, but still I'm impressed :-) > > - Even fdelay4 is not up to the task. There are > gain variations of more than 6dB for a 20 kHz > signal, Fs = 48 kHz. Even stranger, they are > not symmetric w.r.t. the fraction of the delay, > e.g. 10.3 samples shows a different gain than > 9.7. Which makes me suspicious. > > - My usual grunge: unless you want me accidentally > destroy some very expensive equipment which is not > even mine, the generated JACK apps > > MUST NOT AUTOCONNECT --- NEVER --- TO ANYTHING. > We discussed this two years ago. I both respect and understand your reasons to take your position on this issue, but I still strongly disagree with you, and I also think its a bit sad that you use such strong wording about an issue which there clearly are two different views upon. Its also sad if you destroy your equipment, but you are actually yourself to blame if it happens. And just to repeat my position: Unless someone can make it probable that most people prefer jack applications not to autoconnect by default, all jack programs should autoconnect by default. Anyway, this is a jack-dev issue, and there are various ways to fix the jack server so that it will be possible to turn off autoconnect [1] for those who prefer so. However, you (the non-autoconnect people) must push this new API or functionality into jack, because the rest of us are satisfied with the current situation where almost all jack clients autoconnect by default, and therefore its unlikely for us to find the motivation to push this. [1] One simple hack you can do is simply just to create some new dummy ports and set those as being the system default instead of the real system default. That hack shouldn't take more than a few hours to implement. If you feel so strongly about this issue, you should make such a modification to jack. Note, this is just a hack to fix the problem temorarily, not a long-term solution.

17 years, 9 months

Jackdmp

by alex stone

As a complete aside to the gaiety and good natured frollocking going in the GPL discussion, I'm writing to say thanks to Stephane and the Jackdmp team. I've installed the latest incarnation (0.69), and it works a treat. The system's never run so well. Thanks fellas, your skill and determination is appreciated. Alex Stone.

17 years, 9 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev