View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000655ardourbugspublic2004-07-30 04:262008-11-20 23:42
Reporterdharper Assigned Topaul  
PriorityurgentSeveritycrashReproducibilityalways
Status closedResolutionfixed 
Summary0000655: Crash on adding ouput ports
DescriptionAfter creating a session with 3 stereo tracks, recording a bit, then
saving and re-opening. Upon re-opening, Ardour reports that it cannot
connect Audio2 and 3 to the master bus. When I check the outputs on the
tracks, there are no output ports, I then click add port twice, but on
the second time, Ardour segfaults.
Additional Informationgdb trace:

Thread 9 (Thread 114696 (LWP 9966)):
#0 0x4110e6fa in poll () from /lib/i686/libc.so.6
0000001 0x08508de0 in ARDOUR::Session::midi_thread_work() ()
#2 0x08508d05 in ARDOUR::Session::_midi_thread_work(void*) ()
#3 0x412a9db2 in pthread_start_thread () from /lib/i686/libpthread.so.0
0000004 0x412a9f45 in pthread_start_thread_event () from
/lib/i686/libpthread.so.0
0000005 0x4111779a in clone () from /lib/i686/libc.so.6
                                                                                                                     
Thread 8 (Thread 98311 (LWP 9965)):
#0 0x412ac0b4 in __pthread_sigsuspend () from /lib/i686/libpthread.so.0
0000001 0x412ab9f8 in __pthread_wait_for_restart_signal ()
   from /lib/i686/libpthread.so.0
#2 0x00000020 in ?? ()
#3 0x449e7bc8 in ?? ()
0000004 0x08ad1c68 in ?? ()
0000005 0x00005a07 in ?? ()
                                                                                                                     
Thread 7 (Thread 81926 (LWP 9964)):
#0 0x00000002 in ?? ()
0000001 0x084908ea in ARDOUR::IO::pan(std::vector<float*,
std::allocator<float*> >&, unsigned, unsigned, float) ()
#2 0x084d887a in
ARDOUR::Route::process_output_buffers(std::vector<float*,
std::allocator<float*> >&, unsigned, unsigned, unsigned, unsigned, bool,
int, bool)
    ()
#3 0x0000000b in ?? ()
0000004 0x08a7e8c8 in ?? ()
0000005 0x00e869dc in ?? ()
                                                                                                                     
Thread 4 (Thread 32771 (LWP 9961)):
#0 0x412ac0b4 in __pthread_sigsuspend () from /lib/i686/libpthread.so.0
0000001 0x412ab9f8 in __pthread_wait_for_restart_signal ()
   from /lib/i686/libpthread.so.0
#2 0x00000020 in ?? ()
#3 0x431e7da8 in ?? ()
0000004 0x087b42b8 in ?? ()
0000005 0x00005a07 in ?? ()
                                                                                                                     
Thread 3 (Thread 16386 (LWP 9960)):
#0 0x41062c1b in sigsuspend () from /lib/i686/libc.so.6
0000001 0x412ac506 in sigwait () from /lib/i686/libpthread.so.0
#2 0x082cafb9 in main ()
                                                                                                                     Thread 2 (Thread 32769 (LWP 9959)):
#0 0x4110e6fa in poll () from /lib/i686/libc.so.6
0000001 0x412a8d1a in __pthread_manager () from /lib/i686/libpthread.so.0
#2 0x412a8fea in __pthread_manager_event () from
/lib/i686/libpthread.so.0
#3 0x4111779a in clone () from /lib/i686/libc.so.6
                                                                                                                     
Thread 1 (Thread 16384 (LWP 9958)):
#0 0x4110e6fa in poll () from /lib/i686/libc.so.6
0000001 0x414bedcb in g_main_is_running () from /usr/lib/libglib-1.2.so.0
#2 0x414be685 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#3 0x414beaf4 in g_main_run () from /usr/lib/libglib-1.2.so.0
0000004 0x417a46af in gtk_main () from /usr/lib/libgtk-1.2.so.0
0000005 0x083c14cc in Gtkmmext::UI::run(Receiver&) ()
#6 0x082c960c in main ()
#0 0x00000002 in ?? ()
TagsNo tags attached.

Activities

dharper

2004-07-30 04:27

reporter   ~0001306

This is reproducable in Ardour version:
0.9beta18.4 (ardour/gtk: 0.526.0 libardour: 0.825.0)

paul

2004-07-30 11:55

administrator   ~0001309

please get the messages from jackd when this happens. i want to know why it can't create/connect the ports.

dharper

2004-08-23 01:42

reporter   ~0001442

OK, here are some more details...

When Ardour loads the session I get this in the Ardour log:
[ERROR]: Unknown connection "0x8cc3b98" listed for input of Bass
[ERROR]: IO: cannot connect input port ardour:Verb/in 1 to ardour:Bass/out 2
[ERROR]: Unknown connection "0x8cc3b98" listed for input of Bass
[ERROR]: IO: cannot connect input port ardour:master/in 1 to ardour:Bass/out 1
[ERROR]: IO: cannot connect input port ardour:master/in 2 to ardour:Bass/out 2

Jack shows:
11:31:06.601 Audio connection change.
11:31:06.606 Audio connection graph change.
unknown source port in attempted connection [ardour:Bass/out 2]
unknown source port in attempted connection [alsa_pcm:capture_8]
unknown source port in attempted connection [alsa_pcm:capture_5]
unknown source port in attempted connection [ardour:Bass/out 1]
unknown source port in attempted connection [ardour:Bass/out 2]
11:31:06.804 Audio connection change.

(ignore the capture errors, I was working on the session with a HDSP and then when portable, was loading it with the built in i810.)

This is a different session, but with the same bug.
Ardour 0.9beta19 ardour/gtk: 0.529.3 libardour: 0.827.4

Dan

dharper

2004-08-23 01:44

reporter   ~0001443

Forgot to mention, ardour crashes in the same manner as before when I try to add the output ports back on the Bass track. The first one works, the second crashes.

Dan

dharper

2004-08-23 02:30

reporter   ~0001444

Ah Ha! Jack does spit out some complaints when Ardour crashes:

12:26:18.657 Audio connection change.
12:26:18.658 Audio connection graph change.
12:26:18.659 XRUN callback. (1)
subgraph starting at ardour timed out (subgraph_wait_fd=22, status = 0, state = Running)
client ardour error: awake_at = 5576590303 state = 2 timed_out = 2
**** alsa_pcm: xrun of at least 2.313 msecs


Here is more detail with verbose switched on:

registered port ardour:AcousticInTime/out 1, offset = 53248
12:28:00.649 Audio connection graph change.
12:28:00.848 Audio connection change.
registered port ardour:AcousticInTime/out 2, offset = 57344
12:28:01.470 Audio connection graph change.
subgraph starting at ardour timed out (subgraph_wait_fd=19, status = 0, state = Running)
at 5679502845 client waiting on 19 took 24392 usecs, status = 1 sig = 5679478449 awa = 5679478459 fin = 0 dur=0
client ardour error: awake_at = 5679478459 state = 2 timed_out = 2
client failure: client ardour state = Running errors = 1
*&*&*&*&** senor ardour - you are a ZOMBIE
DIS-connect ardour:master/out 2 and alsa_pcm:playback_2
DIS-connect ardour:master/out 1 and alsa_pcm:playback_1
DIS-connect ardour:Audio 2/out 2 and ardour:master/in 2
DIS-connect ardour:ElecDrums/out 2 and ardour:master/in 2
DIS-connect ardour:Audio 2/out 1 and ardour:master/in 1
DIS-connect ardour:Audio 1/out 1 and ardour:master/in 1
DIS-connect ardour:ElecDrums/out 1 and ardour:master/in 1
DIS-connect alsa_pcm:capture_2 and ardour:Audio 2/in 1
DIS-connect ardour:auditioner/out 2 and alsa_pcm:playback_2
DIS-connect ardour:auditioner/out 1 and alsa_pcm:playback_1
timebase master exit
++ jack_rechain_graph():
client qjackctl-5450: start_fd=5, execution_order=0.
client qjackctl-5450: wait_fd=16, execution_order=1.
client alsa_pcm: internal client, execution_order=2.
-- jack_rechain_graph()
**** alsa_pcm: xrun of at least 1.762 msecs
12:28:01.517 XRUN callback. (1)
load = 0.9276 max usecs: 18.000, spare = 23201.000
load = 0.5133 max usecs: 23.000, spare = 23196.000


Yes, this is another session with the same bug (hopefully it doesn't matter too much).

Dan

dharper

2004-09-05 23:35

reporter   ~0001466

OK, if it helps, I'm suspecting that the problem occurs when I switch sound cards. I've got a session that I recorded with my HDSP which I worked on all weekend without problems, opening and closing it a few times. But, today, when I start jack for the internal i8x0 sound card and try to open the session, it Ardour crashes and the errors in the log look similar to the errors with the other problems reported with this bug.

So, it seems that whatever session I create with the HDSP I can only work on with the HDSP, which of course is a serious issue.

Cheers,
Dan

dharper

2004-09-06 01:51

reporter   ~0001467

OK, here is some more info. It seems to be a problem with panner states.

This issue has had several effects. Initially I was unable to open the session, the Ardour log showed something like:
[ERROR]: Unknown connection "0x8cc3b98" listed for input of Bass
as previously, except the hex value and track was different as it is a different sesison.

Then I tried 3 or 4 times to open it, eventually it did open.

Now the track in question had no outputs assigned, similar to when the problem appeared in the previous problem sessions. I decided to leave it as is for a while, and messed around with some other things. I saved the session and then exited, everything seemed fine. Now I could open and close the session with no problems and no errors, except the problem with the outputs on that particular track was still present. So I decided to add the outputs back. I added one, fine. Then when I added the second, the crash occurred again.

Now when I try to open the session, X locks up, I needed to go to another terminal to kill ardour, jack and qjackctl.

I rebuilt the latest CVS with dev build and no optimisation. And tested in gdb. X locked again. Killed it all and tried again. This time the session opened, and I see this in my terminal:

[dharper@laptank ardour-cvs-04-openfix]$ gdb gtk_ardour/ardour
GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run
Starting program: /home/dharper/downloads/ardour-cvs-04-openfix/gtk_ardour/ardour
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 31859)]
[New Thread 32769 (LWP 31860)]
[New Thread 16386 (LWP 31861)]
Ardour/GTK 0.531.1 running with libardour 0.830.0
Loading UI configuration file /home/dharper/.ardour/ardour_ui.rc
Loading system configuration file /home/dharper/.ardour/ardour_system.rc
Loading user configuration file /home/dharper/.ardour/ardour.rc
ardour: [WARNING]: No MMC control (MIDI port "hw:0" not available)
file_set_error: No such device or address
[New Thread 32771 (LWP 31865)]
[New Thread 49156 (LWP 31866)]
Use of deprecated SAXv1 function internalSubset
ardour: [INFO]: detecting VST plugins along /usr/local/lib/vst:/usr/lib/vst
ardour: [WARNING]: Your system generates "Mod2" when the NumLock key is pressed. This can cause problems when editing so Ardour will use Mod3 to mean Meta rather than Mod2
ardour: [ERROR]: KeyboardTarget: unknown action "edit-cursor-to-selection-start"
ardour: [ERROR]: KeyboardTarget: unknown action "edit-cursor-to-selection-end"
ardour: [ERROR]: KeyboardTarget: unknown action "set-mouse-mode-scrub"
ardour: [ERROR]: KeyboardTarget: unknown action "start-selection"
ardour: [ERROR]: KeyboardTarget: unknown action "finish-selection"
ardour: [ERROR]: KeyboardTarget: unknown action "extend-selection-to-end-of-region"
ardour: [ERROR]: KeyboardTarget: unknown action "extend-selection-to-start-of-region"
ardour: [ERROR]: KeyboardTarget: unknown action "duplicate-selection"
ardour: [ERROR]: KeyboardTarget: unknown action "split-region"
[New Thread 65541 (LWP 31867)]
[New Thread 81926 (LWP 31868)]
Loading session /home/dharper/audio/Melissa_p-20040904 using snapshot Melissa_p-20040904
[New Thread 98311 (LWP 31869)]
[New Thread 114696 (LWP 31870)]
finished route resort
 master
finished route resort
 master MelGuitarMic
finished route resort
 master MelGuitarMic RozVox
finished route resort
 master MelGuitarMic RozVox JuliaPerc
finished route resort
 master MelGuitarMic RozVox JuliaPerc StephPerc
finished route resort
 master MelGuitarMic RozVox JuliaPerc StephPerc MelGuitarPickup
finished route resort
 master MelGuitarMic RozVox JuliaPerc StephPerc MelGuitarPickup MelVox
finished route resort
 master MelGuitarMic RozVox JuliaPerc StephPerc MelGuitarPickup MelVox DanPodR
finished route resort
 master MelGuitarMic RozVox JuliaPerc StephPerc MelGuitarPickup MelVox DanPodR Audio 8
finished route resort
 master MelGuitarMic RozVox JuliaPerc StephPerc MelGuitarPickup MelVox DanPodR Audio 8 Reverb
finished route resort
 master MelGuitarMic RozVox JuliaPerc StephPerc MelGuitarPickup MelVox DanPodR Audio 8 Reverb
finished route resort
 master MelGuitarMic RozVox JuliaPerc StephPerc MelGuitarPickup MelVox DanPodR Audio 8 Reverb
finished route resort
 MelGuitarMic RozVox JuliaPerc Audio 8 Reverb master StephPerc MelGuitarPickup MelVox DanPodR


Which looks OK so far.
I go to add that dreaded second input and get this:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 81926 (LWP 31868)]
0x085b3bde in ARDOUR::IO::pan(std::vector<float*, std::allocator<float*> >&, unsigned long, unsigned, unsigned, float) () at xml++.cc:12
12 XMLTree::XMLTree()
Current language: auto; currently c++
(gdb)


Ah ha! The problem seems related to panner code. One thing here that I always suspected... Why is the code referencing XML? I haven't decided to save my session file, so why is Ardour worried about XML? I've noticed the following about Ardour that concerns me:

1. Sometimes if Ardour crashes while I'm in the middle of something, some changes that I've made since the last save have actually appeared in the session file. But I haven't saved those changes! Ardour seesm to automatically save the session at certain points. It worries me, because if I'm trying something out I don't want to save yet (I want to be sure it works) then I don't want Ardour being a smart aleck and saving these changes before I'm comfortable to commit to my precious session file. (Editing can take a long time, don't increase the risk of me doing it all over again!)

2. The XML code (which is a library no?) is very unstable. I've always noticed Ardour having the most problems saving or loading a session file. I don't think that whizz-bang features are a priority while Ardour cannot even reliably save and open a session file. There is no verification that Ardour has properly saved the XML file. And the response to an error loading an XML file is commonly a segfault.

3. Bugs like this now become complex to track down due to Ardour playing with XML when I'm trying to add a port. I'm not trying to save a session, so don't make me! I think because of the instability of the XML code, and because Ardour plays with it far too often outside of opening and saving a file, it causes many instabilities in Ardour.


Anyway, here is the trace:
(gdb) thread apply all bt

Thread 9 (Thread 114696 (LWP 31870)):
#0 0x4110e6fa in poll () from /lib/i686/libc.so.6
0000001 0x086358e7 in ARDOUR::Session::midi_thread_work() () at xml++.cc:12
#2 0x086356e5 in ARDOUR::Session::_midi_thread_work(void*) () at xml++.cc:12
#3 0x412a9db2 in pthread_start_thread () from /lib/i686/libpthread.so.0
0000004 0x412a9f45 in pthread_start_thread_event () from /lib/i686/libpthread.so.0
0000005 0x4111779a in clone () from /lib/i686/libc.so.6

Thread 8 (Thread 98311 (LWP 31869)):
#0 0x412ac0b4 in __pthread_sigsuspend () from /lib/i686/libpthread.so.0
0000001 0x412ab9f8 in __pthread_wait_for_restart_signal () from /lib/i686/libpthread.so.0
#2 0x00000020 in ?? ()

Thread 7 (Thread 81926 (LWP 31868)):
#0 0x085b3bde in ARDOUR::IO::pan(std::vector<float*, std::allocator<float*> >&, unsigned long, unsigned, unsigned, float) () at xml++.cc:12
0000001 0x085fde51 in ARDOUR::Route::process_output_buffers(std::vector<float*, std::allocator<float*> >&, unsigned long, unsigned, unsigned, unsigned, unsigned, bool, int, bool) () at xml++.cc:12
#2 0x085728d9 in ARDOUR::AudioTrack::passthru_silence(unsigned, unsigned, unsigned, unsigned, int) ()
    at xml++.cc:12
#3 0x08572a71 in ARDOUR::AudioTrack::no_roll(unsigned, unsigned, unsigned, unsigned, bool, bool, bool) ()
    at xml++.cc:12
0000004 0x08637e7b in ARDOUR::Session::no_roll(unsigned, unsigned) () at xml++.cc:12
0000005 0x08638eb3 in ARDOUR::Session::process_without_events(unsigned) () at xml++.cc:12
#6 0x0863855b in ARDOUR::Session::process_with_events(unsigned) () at xml++.cc:12
#7 0x08637c4f in ARDOUR::Session::process(unsigned) () at xml++.cc:12
0000008 0x08552072 in ARDOUR::AudioEngine::process_callback(unsigned) () at xml++.cc:12
0000009 0x08551d22 in ARDOUR::AudioEngine::_process_callback(unsigned, void*) () at xml++.cc:12
0000010 0x41b8036a in jack_port_type_size () from /usr/lib/libjack.so.0
0000011 0x00000400 in ?? ()
0000012 0x08920608 in ?? ()
0000013 0x0000063a in ?? ()

Thread 6 (Thread 65541 (LWP 31867)):
#0 0x412ac0b4 in __pthread_sigsuspend () from /lib/i686/libpthread.so.0
0000001 0x412ab9f8 in __pthread_wait_for_restart_signal () from /lib/i686/libpthread.so.0
#2 0x00000020 in ?? ()

Thread 5 (Thread 49156 (LWP 31866)):
#0 0x412af15b in read () from /lib/i686/libpthread.so.0
0000001 0x40d23e24 in ?? () from /usr/lib/wine/ntdll.dll.so

Thread 4 (Thread 32771 (LWP 31865)):
#0 0x412af15b in read () from /lib/i686/libpthread.so.0
0000001 0x4003249c in __JCR_LIST__ () from /usr/local/lib/libfst.so

Thread 3 (Thread 16386 (LWP 31861)):
#0 0x41062c1b in sigsuspend () from /lib/i686/libc.so.6
0000001 0x412ac506 in sigwait () from /lib/i686/libpthread.so.0
#2 0x083cf485 in signal_thread(void*) () at xml++.cc:12
#3 0x412a9db2 in pthread_start_thread () from /lib/i686/libpthread.so.0
0000004 0x412a9f45 in pthread_start_thread_event () from /lib/i686/libpthread.so.0
0000005 0x4111779a in clone () from /lib/i686/libc.so.6

Thread 2 (Thread 32769 (LWP 31860)):
#0 0x4110e6fa in poll () from /lib/i686/libc.so.6
0000001 0x412a8d1a in __pthread_manager () from /lib/i686/libpthread.so.0
#2 0x412a8fea in __pthread_manager_event () from /lib/i686/libpthread.so.0
#3 0x4111779a in clone () from /lib/i686/libc.so.6

Thread 1 (Thread 16384 (LWP 31859)):
#0 0x4110e6fa in poll () from /lib/i686/libc.so.6
0000001 0x414bedcb in g_main_is_running () from /usr/lib/libglib-1.2.so.0
#2 0x414be685 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#3 0x414beaf4 in g_main_run () from /usr/lib/libglib-1.2.so.0
0000004 0x417a46af in gtk_main () from /usr/lib/libgtk-1.2.so.0
0000005 0x08249cf1 in Gtk::Main::run() () at main.h:168
#6 0x084e2d4e in Gtkmmext::UI::run(Receiver&) (this=0x881f610, old_receiver=@0x880c160) at gtk_ui.cc:168
#7 0x083d0a8d in main () at xml++.cc:12
0x085b3bde 12 XMLTree::XMLTree()

dharper

2004-09-06 02:42

reporter   ~0001468

Cool.

Some more info...

I found that the original session file, if you close it and re-open it multiple times without saving, you get these errors in the file:

[ERROR]: Unknown connection "0x9081818" listed for input StephPerc

The thing is, every time I open the session, the hex value changes:
0x9081b40
0x9080780
0x9081a00
0x9081818

None of these values exist in the session file. Maybe Ardour is grabbing memory it shouldn't be?

Dan

tito

2004-09-11 07:15

reporter   ~0001472

Does increasing the -p value to jack change anything? This is "Port Maximum" on qjackctl's setup page.

dharper

2004-09-13 02:47

reporter   ~0001473

The port maximum value changing made no difference.

But, I've _finally_ found a work around to get the session back!

Both the inputs and outputs for the track are missing when this error occurs. If I place an input back into the track before I put the 2 output ports back everything goes back to normal.

So, this looks like 2 bugs.

One, where the session file is not correctly saved, causing the original error.

Two, when there are no inputs, if you try to add more than one output on a track, Ardour will segfault.

Dan

paul

2004-10-13 15:31

administrator   ~0001498

Dan: I'll try to address some of your concerns mentioned:

---------------------------
1. Sometimes if Ardour crashes while I'm in the middle of something, some changes that I've made since the last save have actually appeared in the session file. But I haven't saved those changes! Ardour seesm to automatically save the session at certain points. It worries me, because if I'm trying something out I don't want to save yet (I want to be sure it works) then I don't want Ardour being a smart aleck and saving these changes before I'm comfortable to commit to my precious session file. (Editing can take a long time, don't increase the risk of me doing it all over again!)
----------------------------

autosave only happens, i think, after a capture. we do this so that if you shutdown or crash before saving, your recorded material is still visible. its obviously on disk either way, but it would be hard to find if we do not do this save. there are no other autosaves that i am aware of right now.

------------------------------
2. The XML code (which is a library no?) is very unstable. I've always noticed Ardour having the most problems saving or loading a session file. I don't think that whizz-bang features are a priority while Ardour cannot even reliably save and open a session file. There is no verification that Ardour has properly saved the XML file. And the response to an error loading an XML file is commonly a segfault.
-------------------------------

if the save fails, ardour will tell you. and problems loading the XML state are not related to it being XML. re-establishing ardour's session state is very, very complex, and presents many difficult design choices. we continue to work on them as we become of new issues.

---------------------------------
3. Bugs like this now become complex to track down due to Ardour playing with XML when I'm trying to add a port. I'm not trying to save a session, so don't make me! I think because of the instability of the XML code, and because Ardour plays with it far too often outside of opening and saving a file, it causes many instabilities in Ardour.
----------------------------------

ardour doesn't "play with XML" outside of session load. the backtrace you see is misleading and caused by problems in gdb. there are elements of session loading that happen in a slightly deferred way. thats about it. i tried to outline why we sometimes autosave above.

paul

2004-10-13 15:41

administrator   ~0001499

dan,

trying to get to the bottom of this issue.

As far as I can tell, you used the "Connections" feature of ardour to hook up various tracks. I would guess that you used named Connections created automatically by ardour that correspond to the physical i/o of your audio interface. In all likelihood, you used a connection that exists only on the hdsp or other multichannel cards, so when you started ardour on a stereo interface, that connection does not exist.

Ardour looks up connections by name. I agree that this is a serious failure, and I am trying to decide what Ardour should do if the connection does not exist. My initial guess is to use the first in or out connection as appropriate.

I have also corrected the error message about the missing connection to properly print the name of the connection. this will show up in CVS soon.

paul

2004-10-13 15:45

administrator   ~0001500

:)

paul

2004-11-01 22:22

administrator   ~0001560

0.9beta21 contains a fix so that if a track/bus uses a named connection that doesn't exist, ardour will fall back on "in 1" or "out 1" as appropriate. its the best solution i could come up with.

Bugtrap

2004-11-04 18:01

reporter   ~0001572

I have a similar issue when trying to use the 32 track template (had to make
a link from my .ardour to the /usr&share/ardour/templates first)
ardour beta21 + multiface

no ports available!
no ports available!
no ports available!
no ports available!
no ports available!
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
unknown destination port in attempted connection [ardour:master/in 1]
unknown destination port in attempted connection [ardour:master/in 2]
no ports available!
no ports available!
no ports available!
no ports available!
no ports available!
no ports available!
Segmentation fault

subgraph starting at ardour timed out (subgraph_wait_fd=11, status = 0, state = Triggered)


**** alsa_pcm: xrun of at least 1.350 msecs

cannot read event response from client [ardour] (Connection reset by peer)
bad status for client event handling (type = 8)


**** alsa_pcm: xrun of at least 137.727 msecs

paul

2005-03-08 18:10

administrator   ~0002102

we need feedback from around 0.9beta27. 1 week, and then i'll mark it resolved, even though the current design is not ideal.

paul

2005-05-06 01:04

administrator   ~0002215

see notes for bug history (and much, much more!)

Issue History

Date Modified Username Field Change
2004-07-30 04:26 dharper New Issue
2004-07-30 04:26 dharper E-mail => tech@danharper.org
2004-07-30 04:26 dharper Name => Dan Harper
2004-07-30 04:27 dharper Note Added: 0001306
2004-07-30 11:55 paul Note Added: 0001309
2004-08-23 01:42 dharper Note Added: 0001442
2004-08-23 01:44 dharper Note Added: 0001443
2004-08-23 02:31 dharper Note Added: 0001444
2004-09-05 23:35 dharper Note Added: 0001466
2004-09-06 01:51 dharper Note Added: 0001467
2004-09-06 02:42 dharper Note Added: 0001468
2004-09-11 07:15 tito Note Added: 0001472
2004-09-13 02:47 dharper Note Added: 0001473
2004-10-13 15:31 paul Note Added: 0001498
2004-10-13 15:41 paul Note Added: 0001499
2004-10-13 15:45 paul Note Added: 0001500
2004-10-13 15:45 paul Status new => confirmed
2004-11-01 22:22 paul Note Added: 0001560
2004-11-03 18:43 paul Status confirmed => feedback
2004-11-04 18:01 Bugtrap Note Added: 0001572
2005-03-08 18:10 paul Note Added: 0002102
2005-05-06 01:04 paul Status feedback => resolved
2005-05-06 01:04 paul Resolution open => fixed
2005-05-06 01:04 paul Assigned To => paul
2005-05-06 01:04 paul Note Added: 0002215
2008-11-20 23:42 seablade Status resolved => closed