From: Pieter P. <pi...@jo...> - 2008-01-14 22:48:26
|
Jonathan Woithe wrote: > Hi Pieter > > I had a chance to test ffado svn845 overnight against jackd svn1082. > Briefly: > > 1) The startup / shutdown issues remain in that the high-pitched tone is > heard during these times. No surprises here since that wasn't addressed > between revisions 833 and 845. > > 2) CPU load has dropped slightly - on my 2 GHz machine it's down from 65% > with rev 833 to around 55% with 845. Still too high but obviously a > move in the right direction. Try a non-debug build with optimizations enabled. It should be way better. > > 3) I'm still getting a segfault on jackd exit but it's not precipitated by > the operation of the watchdog anymore. I didn't have time to chase this > extensively. A core dump indicated the segfault occured as a result of > the getName() method call in PortManager::~PortManager() on line 47 of > src/libstreaming/generic/PortManager.cpp. It was faulting while dealing > with one of the MIDI ports. My theory at present is that the MIDI ports > might be freed elsewhere (in a throwback to the previous MIDI port > arrangement) but not unregistered. This may mean that the MIDI ports > have already been destroyed by the time PortManager::~PortManager() runs. > At this point though this is just all idle speculation on my part. I have the same segfault, it's on the todo list. > > In relation to (1) I must say I'm somewhat confused about what is meant to > occur in the different states, what the various methods in > MotuTransmitStreamProcessor.cpp are meant to do and how these methods relate > to the different states. We seem to have "data" packets, "empty" packets > and "silence" packets, although "empty" and "silence" packets currently seem > to both do the same thing (return a header only packet with length 8). In > my view "silence" packets should be data packets with the audio data all set > to zero. If this is the intention I can't quite see how the current code is > meant to achieve this. I see your point. I'll try and fix it. > > Finally I note in StreamProcessor.h that the ePS_WaitingToStop state (which > as the comment says will be needed for MOTU) has been commented out. I > therefore conclude that this state has not yet been implemented. If this is > the only way of sending zeroed audio data to the MOTU on closedown (which is > needed to prevent the nasty high-pitched tones on shutdown and the next > startup) then there probably isn't much I can do on the MOTU side until the > base infrastructure implements this. On the other hand, perhaps you've > rolled this into the DryRunning state, but if so it's not clear to me how > the MOTU streaming code should deal with the DryRunning state. I hope to not need it since the state stuff is already rather complex. Let me chew on it for a while. Greets, Pieter |