Hmm... Problem disappeared (solved). With Debian Sid (unstable) I have:
timidity 2.13.2-20 jackd and libjack0 0.116.1-2 Some how I got an error when trying to connect Kmid to timidity before. Timidity started fine with timidity -iA -B2,8 -Oj but when trying to connect kmid to it, timidity gave error that it couldn't open a connection to JACK, something similar to when jackd hadn't started: .Couldn't open JACK device (`j') Timidity stopped then. I did check and made sure that jackd had started but still got the same error then. Even with the CVS version of timidity in /usr/local didn't help until I change to use the new jack clien API. Now, after a reboot a couple of days later (I only reboot once in a while), both timidity versions I have seem to work fine with jackd. So, please ignore my previous post about the new jackd API call. If anyone knows the culprit, I'd like to know. Thanks, Jimmy --- On Thu, 1/15/09, jimmy <[email protected]> wrote: > From: jimmy <[email protected]> > Subject: Timidity and recent jackd releases -- WAS -- re: Running Timidity > as a service > To: [email protected] > Date: Thursday, January 15, 2009, 9:08 AM > FYI, regarding Timidity with recent jackd versions. Hope it > may save some of you some time along the way. > > With Debian Sid (Unstable), I have > > jackd and libjack0 version 0.116.1-2 > custom kernel 2.6.25.9 with high resolution timer > Timidity CVS extracted 20090108 > > Hardware: > > Intel 2.4GHz (old) CPU. > Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 > Creative Labs SB Live! 5/1 > > besides the fact that it didn't work until I tried > changing jack_client_new() to using jack_client_open() in > timidity/jack_a.c as previously posted. > > If someone with CVS write access wants to, please do update > the Timidity code base. But the Timidity project lead may > want to do a point release of the Timidity code first, so > anyone who want or need to use the code for older jackd can > still use the code up to now. Since the new jackd verion > breaks the old jack_clien_new() API. > > Anyway, my use of buffer parameters used to be -B2,8 as in: > > timidity -iAD -B2,8 -Oj > > results in slow, stretched-out, noisy sounds. So I tried > using: > > timidity -iAD -B2,12 -Oj > > That sounded OK but there is a time lag in the play-back. > The play-back time lag improves slightly with: > > timidity -iAD -B2,10 -Oj > > But when I tried playing along with vkeybd, that didn't > work very well for real-time. Finally trying: > > timidity -iAD -B1,10 -Oj > > seems to work best for me with both midi playback and > vkeybd usage concurrently. > > Jimmy > > > > --- On Thu, 1/15/09, jimmy <[email protected]> wrote: > > > From: jimmy <[email protected]> > > Subject: re: Running Timidity as a service > > To: [email protected] > > Date: Thursday, January 15, 2009, 7:15 AM > > > Date: Tue, 13 Jan 2009 19:29:48 +0000 > > > From: Jonathan Gazeley > > > <[email protected]> > > > Subject: [timidity-talk] Running Timidity as a > service > > > > . . . > > > > > [jonat...@poseidon ~]$ sudo service timidity > start > > > [jonat...@poseidon ~]$ file mcoputils.cc: line > 499 > > (static > > > std::string > > > Arts::MCOPUtils::mcopDirectory()): assertion > failed: > > (home > > > != 0) > > > HOME environment variable not set? > > > jack_client_new: deprecated > > > Cannot connect to server socket err = No such > file or > > > directory > > > Cannot connect to server socket > > > jack server is not running or cannot be started > > > no message buffer overruns > > > Couldn't open output device > > > > > > > > > I tested that I can successfully run timidity > using > > sudo: > > > > > > [jonat...@poseidon ~]$ sudo timidity -iA > > > TiMidity starting in ALSA server mode > > > Opening sequencer port: 128:0 128:1 128:2 128:3 > > > > > > Does anyone have any ideas what might be up? > > > > > > Cheers, > > > Jonathan > > > > I use Debian, not Fedora, so there might be some > config > > differences. > > > > I don't know about the HOME environment thing > right off > > the bat. If someone knows, please answer. Else, > someone > > may have to look into Timidity source code to figure > out. > > > > As for server socket error, and "jack server is > not > > running or cannot be started", I think it is one > and > > the same. The problem is the new "jackd" > version, > > the message "jack_client_new: deprecated" > points > > to the real cause. > > > > Timidity code still uses jack_client_new() as a mean > to > > connect to jackd. However, with the new jackd, and > libjack0 > > both are at version 0.116.1-2 in Debian Sid > (unstable), the > > call to jack_client_new() doesn't seem to work. > > > > I tried the following code in jack_a.c > > > > static int detect(void) > > { > > jack_client_t *client; > > jack_status_t status; > > /* ---OLD--- client = > > jack_client_new(TIMIDITY_JACK_CLIENT_NAME); */ > > /* open a connection to the JACK server */ > > client = jack_client_open (TIMIDITY_JACK_CLIENT_NAME, > > JackNullOption, &status); > > if (! client) { > > ctl->cmsg(CMSG_ERROR, VERB_NORMAL, > > "jack_client_open() failed, status = > > 0x%2.0x\n", status); > > return 0; > > } > > > > jack_client_close(client); > > return 1; /* found */ > > } > > > > > > and equivalent code in > > > > static int open_jack(void) > > > > function of the same file. It seems jackd > deliberately > > breaks that old jack_client_new() API call. > Otherwise, they > > could have easily use similar code as shown above to > > implement jack_client_new(), which is simple enough to > keep > > old apps working without changes. Either that or they > > don't care for backward compatibility in this > case, and > > force everyone to use new code. > > > > Jimmy ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Timidity-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/timidity-talk
