From: Jonathan W. <jw...@ph...> - 2007-12-13 22:39:07
|
Hi Pieter > I would like to push out a release ASAP. This due to the fact that the > first quarter of 2008 will be hectic for me, and I won't be having an > spare time for FFADO. After March, things should should ease up for me. > So basically it's now or in April. Fair enough - now seems somewhat preferable. > Hence I'm going to try and get the codebase in an acceptable shape (e.g. > undo some thing's I've done over the last weeks) and try and get the API > in shape. Then we'll have to go into beta. Sounds like a fair plan. > I don't know where we are for the other things, e.g. MotU? I *think* MOTU's looking pretty good although I haven't had a chance to extensively test it after the last lot of streaming updates went in. Brief tests suggest that it's better than the pre-streaming update code but there are a few things I still need to test before I can be sure of this. I haven't had time in recent weeks due to a recording gig and preparations for that (for which I reverted to a pre-ffado freebob snapshot I know is stable for MOTU). Furthermore, I haven't tested an svn version beyond 750 so I don't know how those latency issues affect MOTU. There's a weekend coming and my recording commitments are now finished - I will try to get some time to exercise the recent svn versions and see how we go. Out of interest, what bits are you looking to undo? > What are the thoughts? In principle I think it would be helpful to push a release out before you get busy early next year with the caveat that we can show that most known issues have been addressed. Regards jonathan |
From: Pieter P. <pi...@jo...> - 2007-12-14 09:43:38
|
Jonathan Woithe wrote: > Hi Pieter > >> I would like to push out a release ASAP. This due to the fact that the >> first quarter of 2008 will be hectic for me, and I won't be having an >> spare time for FFADO. After March, things should should ease up for me. >> So basically it's now or in April. > > Fair enough - now seems somewhat preferable. > >> Hence I'm going to try and get the codebase in an acceptable shape (e.g. >> undo some thing's I've done over the last weeks) and try and get the API >> in shape. Then we'll have to go into beta. > > Sounds like a fair plan. > >> I don't know where we are for the other things, e.g. MotU? > > I *think* MOTU's looking pretty good although I haven't had a chance to > extensively test it after the last lot of streaming updates went in. Brief > tests suggest that it's better than the pre-streaming update code but there > are a few things I still need to test before I can be sure of this. I > haven't had time in recent weeks due to a recording gig and preparations for > that (for which I reverted to a pre-ffado freebob snapshot I know is stable > for MOTU). Furthermore, I haven't tested an svn version beyond 750 so I > don't know how those latency issues affect MOTU. > > There's a weekend coming and my recording commitments are now finished - I > will try to get some time to exercise the recent svn versions and see how we > go. It would be nice if motu support is ready for this release. > > Out of interest, what bits are you looking to undo? Starting from SVN r750 I moved the streaming 1394 code to libieee1394. This means that I moved IsoStream, IsoHandler and IsoHandlerManager to libieee1394. This introduced some changes which I expected to be insignificant, but which seem to have some side-effects. Some side by side comparisons: pre 750: - only one 1394 port can be used (one ieee1394service). - the IsoHandlerManager is created by the devicemanager, exists together with the 1394service - the IsoHandlerManager had one thread that polled all IsoHandlers' file descriptors at once and then iterated the IsoHandlers from 750: - every port detected gets an ieee1394service. devices get detected regardless of the port they are attached to. The FFADODevices get the 1394service of their port - the IsoHandlerManager is created by the 1394service, i.e. every 1394service has an IsoHandlerManager. FFADODevices can access (register themselves) to the manager through their 1394service. - every IsoHandler has it's own thread to poll it's fd and iterate - IsoStream is removed as it only added overhead. In general the number of virtual functions in the 'critical path' are reduced In my opinion the changes make sense, but they did hurt reliability in one way or another. I sill have to figure that out. > >> What are the thoughts? > > In principle I think it would be helpful to push a release out before you > get busy early next year with the caveat that we can show that most known > issues have been addressed. By waiting another 4 months we hurt our credibility. By rolling out bad code we also do. So I guess we'll have to ship the code we have if it doesn't have serious flaws, but with the limitations explicitly stated. The most critical one being the fact that there is no low latency operation. Greets, Pieter |
From: Jonathan W. <jw...@ph...> - 2007-12-17 06:05:01
|
> >> I don't know where we are for the other things, e.g. MotU? > > > > I *think* MOTU's looking pretty good although I haven't had a chance to > > extensively test it after the last lot of streaming updates went in. Brief > > tests suggest that it's better than the pre-streaming update code but there > > are a few things I still need to test before I can be sure of this. I > > haven't had time in recent weeks due to a recording gig and preparations for > > that (for which I reverted to a pre-ffado freebob snapshot I know is stable > > for MOTU). Furthermore, I haven't tested an svn version beyond 750 so I > > don't know how those latency issues affect MOTU. > > > > There's a weekend coming and my recording commitments are now finished - I > > will try to get some time to exercise the recent svn versions and see how we > > go. > It would be nice if motu support is ready for this release. I agree. The weekend turned out busier than I expected but I hope to take a look at things during this week. > > Out of interest, what bits are you looking to undo? > Starting from SVN r750 I moved the streaming 1394 code to libieee1394. > This means that I moved IsoStream, IsoHandler and IsoHandlerManager to > libieee1394. This introduced some changes which I expected to be > insignificant, but which seem to have some side-effects. > : > In my opinion the changes make sense, but they did hurt reliability in > one way or another. I sill have to figure that out. Sure. I wonder whether they just added that little bit of extra overhead which tipped things over the edge (so to speak). > >> What are the thoughts? > > > > In principle I think it would be helpful to push a release out before you > > get busy early next year with the caveat that we can show that most known > > issues have been addressed. > > By waiting another 4 months we hurt our credibility. By rolling out bad > code we also do. So I guess we'll have to ship the code we have if it > doesn't have serious flaws, but with the limitations explicitly stated. > The most critical one being the fact that there is no low latency operation. I agree with all these points - in particular we can't afford to wait another 4 months. At the same time we should obviously try hard to minimise the number of limitations. What date were you thinking of for a release? Regards jonathan |
From: Pieter P. <pi...@jo...> - 2007-12-17 09:15:07
|
Jonathan Woithe wrote: >>>> I don't know where we are for the other things, e.g. MotU? >>> I *think* MOTU's looking pretty good although I haven't had a chance to >>> extensively test it after the last lot of streaming updates went in. Brief >>> tests suggest that it's better than the pre-streaming update code but there >>> are a few things I still need to test before I can be sure of this. I >>> haven't had time in recent weeks due to a recording gig and preparations for >>> that (for which I reverted to a pre-ffado freebob snapshot I know is stable >>> for MOTU). Furthermore, I haven't tested an svn version beyond 750 so I >>> don't know how those latency issues affect MOTU. >>> >>> There's a weekend coming and my recording commitments are now finished - I >>> will try to get some time to exercise the recent svn versions and see how we >>> go. >> It would be nice if motu support is ready for this release. > > I agree. The weekend turned out busier than I expected but I hope to take a > look at things during this week. > >>> Out of interest, what bits are you looking to undo? >> Starting from SVN r750 I moved the streaming 1394 code to libieee1394. >> This means that I moved IsoStream, IsoHandler and IsoHandlerManager to >> libieee1394. This introduced some changes which I expected to be >> insignificant, but which seem to have some side-effects. >> : >> In my opinion the changes make sense, but they did hurt reliability in >> one way or another. I sill have to figure that out. > > Sure. I wonder whether they just added that little bit of extra overhead > which tipped things over the edge (so to speak). My suspicions at this time are: - a few places that have locks but should be lock-free (I'm going to do RCU for them) - too much debug code in the handlers - no optimization flags: some variables have been replaced by getter functions (e.g. m_1394service => m_parent.get1394service(), which is {return m_1394service;} ). This should not be a big deal since it _should_ come down to the same when optimizing (at least I think so). But without optimizations these are extra function calls. > >>>> What are the thoughts? >>> In principle I think it would be helpful to push a release out before you >>> get busy early next year with the caveat that we can show that most known >>> issues have been addressed. >> By waiting another 4 months we hurt our credibility. By rolling out bad >> code we also do. So I guess we'll have to ship the code we have if it >> doesn't have serious flaws, but with the limitations explicitly stated. >> The most critical one being the fact that there is no low latency operation. > > I agree with all these points - in particular we can't afford to wait > another 4 months. At the same time we should obviously try hard to minimise > the number of limitations. What date were you thinking of for a release? I would like to have a 'release candidate' (or a very good beta) out by dec 31. The main limitation left at this moment is the latency of the system. Pieter |
From: Jonathan W. <jw...@ph...> - 2007-12-17 23:05:43
|
Hi Pieter > > I agree. The weekend turned out busier than I expected but I hope to take a > > look at things during this week. I gave svn-761 a go overnight. It has definitely regressed big-time since svn-748. Whereas with svn-748 I was able to run for several hours without major issues, svn-761 looses sync very quickly - often within 2 minutes of starting jackd. This is with jack svn-1068. Jack command line is something like jackd -R -P 60 -dfirewire -p 1024 -n 4 I tried with larger buffers - going up to 4096 - but that didn't improve things. In fact with a buffer size of 4096 it was probably worse than with 1024. The kernel was 2.6.23.9-rt12 with "low latency deskstop" setting and the firewire IRQ running at elevated priority. What buffer size and number-of-buffers have you had success with? ffado was compiled with DEBUG enabled (but I noted that I saw only 4 debug lines printed and these were only during startup). Obviously there are lots of significant changes between svn-748 and svn-761. I'll grab the patchsets between these two revisions and try to work out exactly which one introduced the problems. It will probably be svn-750 as you have noted but I'd like to confirm this. One other thing I'm wondering about is the DLL used to read the cycle timer which was introduced at some point around this time - because the MOTU is so particular about its time stamps I wonder whether this has something to do with the trouble. It shouldn't, but you never know. The other thing I'm wondering about is the strangeness you've noticed in the ieee1394 kernel stack over the last few days. Your observation that packets were taking a long time to be delivered matches what I've seen in the past. I think this delay was at least part of the reason the MOTU failed to start correctly at very low latencies with the previous streaming system - the buffers were so small that the delivery delay meant that packets required for synchronisation weren't seen in time. > >>> Out of interest, what bits are you looking to undo? > >> Starting from SVN r750 I moved the streaming 1394 code to libieee1394. > >> : > >> In my opinion the changes make sense, but they did hurt reliability in > >> one way or another. I sill have to figure that out. > > > > Sure. I wonder whether they just added that little bit of extra overhead > > which tipped things over the edge (so to speak). > > My suspicions at this time are: > - a few places that have locks but should be lock-free (I'm going to do > RCU for them) > - too much debug code in the handlers > - no optimization flags: some variables have been replaced by getter > functions (e.g. m_1394service => m_parent.get1394service(), which is > {return m_1394service;} ). This should not be a big deal since it > _should_ come down to the same when optimizing (at least I think so). > But without optimizations these are extra function calls. These are all good candidates, I agree. I suspect that each by themselves is not sufficient but together they could cause issues. > > I agree with all these points - in particular we can't afford to wait > > another 4 months. At the same time we should obviously try hard to minimise > > the number of limitations. What date were you thinking of for a release? > I would like to have a 'release candidate' (or a very good beta) out by > dec 31. > > The main limitation left at this moment is the latency of the system. And the regression with MOTU between svn-748 and svn761. :-) Regards jonathan |
From: Pieter P. <pi...@jo...> - 2007-12-18 08:49:39
|
Jonathan Woithe wrote: > Hi Pieter > >>> I agree. The weekend turned out busier than I expected but I hope to take a >>> look at things during this week. > > I gave svn-761 a go overnight. It has definitely regressed big-time since > svn-748. Whereas with svn-748 I was able to run for several hours without > major issues, svn-761 looses sync very quickly - often within 2 minutes of > starting jackd. This is with jack svn-1068. Jack command line is something > like > > jackd -R -P 60 -dfirewire -p 1024 -n 4 > > I tried with larger buffers - going up to 4096 - but that didn't improve > things. In fact with a buffer size of 4096 it was probably worse than with > 1024. The kernel was 2.6.23.9-rt12 with "low latency deskstop" setting and > the firewire IRQ running at elevated priority. > > What buffer size and number-of-buffers have you had success with? None :). it always crashes at some point. > > ffado was compiled with DEBUG enabled (but I noted that I saw only 4 debug > lines printed and these were only during startup). the jack backend now has a '-v' option with which you can specify the debuglevel to be used (e.g. -v6 = DEBUG_LEVEL_VERBOSE). > > Obviously there are lots of significant changes between svn-748 and svn-761. > I'll grab the patchsets between these two revisions and try to work out > exactly which one introduced the problems. It will probably be svn-750 as > you have noted but I'd like to confirm this. One other thing I'm wondering > about is the DLL used to read the cycle timer which was introduced at some > point around this time - because the MOTU is so particular about its time > stamps I wonder whether this has something to do with the trouble. It > shouldn't, but you never know. It would be cool if you could figure it out, because I can't seem to find it. What I do know is that there is something that causes the transmit DMA buffer of the ohci card to become empty. The cycle timer DLL shouldn't be an issue, but in recent revisions you can turn it off using a #define. That should revert back to the original behavior, and for me doesn't seem to influence things for the better. I do suspect however that the DLL isn't bug-free yet (I've seen non-continuous timestamps) > > The other thing I'm wondering about is the strangeness you've noticed in the > ieee1394 kernel stack over the last few days. Your observation that packets > were taking a long time to be delivered matches what I've seen in the past. > I think this delay was at least part of the reason the MOTU failed to start > correctly at very low latencies with the previous streaming system - the > buffers were so small that the delivery delay meant that packets required > for synchronisation weren't seen in time. The firewire stack does seem to be a serious blocker for FFADO. It could be that we're to blame (since freebob works at low latencies), but OTOH I don't think so. Due to the timestamping it's also not fair to compare the latencies of both. The new system (for AMDTP compliant devices) causes the total round-trip latency to be N x period_size (as measured in jdelay). So it will always be higher than other systems, since it includes all intermediate (hardware) buffers. I'm wondering whether it's worthwhile to spend a lot of effort in getting FFADO at low latencies with the old stack. The API of the new stack is a lot better for latency, and frankly I'm getting a bit frustrated of trying to figure out what's happening with the old one. > >>>>> Out of interest, what bits are you looking to undo? >>>> Starting from SVN r750 I moved the streaming 1394 code to libieee1394. >>>> : >>>> In my opinion the changes make sense, but they did hurt reliability in >>>> one way or another. I sill have to figure that out. >>> Sure. I wonder whether they just added that little bit of extra overhead >>> which tipped things over the edge (so to speak). >> My suspicions at this time are: >> - a few places that have locks but should be lock-free (I'm going to do >> RCU for them) >> - too much debug code in the handlers >> - no optimization flags: some variables have been replaced by getter >> functions (e.g. m_1394service => m_parent.get1394service(), which is >> {return m_1394service;} ). This should not be a big deal since it >> _should_ come down to the same when optimizing (at least I think so). >> But without optimizations these are extra function calls. > > These are all good candidates, I agree. I suspect that each by themselves > is not sufficient but together they could cause issues. except for the RCU stuff, they are rather easy to fix. We could cache the 1394service reference and others. We could also weed out the excessive debug statements. > >>> I agree with all these points - in particular we can't afford to wait >>> another 4 months. At the same time we should obviously try hard to minimise >>> the number of limitations. What date were you thinking of for a release? >> I would like to have a 'release candidate' (or a very good beta) out by >> dec 31. >> >> The main limitation left at this moment is the latency of the system. > > And the regression with MOTU between svn-748 and svn761. :-) of course :). Pieter |
From: Jonathan W. <jw...@ph...> - 2007-12-18 23:58:28
|
Hi Pieter > > I gave svn-761 a go overnight. It has definitely regressed big-time since > > svn-748. Whereas with svn-748 I was able to run for several hours without > > major issues, svn-761 looses sync very quickly - often within 2 minutes of > > starting jackd. ... > > : > > What buffer size and number-of-buffers have you had success with? > None :). it always crashes at some point. Ah. Ok, so this is more than likely not a MOTU-specific issue. That's nice (in a way). > the jack backend now has a '-v' option with which you can specify the > debuglevel to be used (e.g. -v6 = DEBUG_LEVEL_VERBOSE). Ah, excellent. Thanks for pointing that out. > > Obviously there are lots of significant changes between svn-748 and svn-761. > > I'll grab the patchsets between these two revisions and try to work out > > exactly which one introduced the problems. ... > > It would be cool if you could figure it out, because I can't seem to > find it. What I do know is that there is something that causes the > transmit DMA buffer of the ohci card to become empty. I'll attack this when I get a chance, which will probably be late this week or over the weekend. > > One other thing I'm wondering about is the DLL used to read the cycle > > timer which was introduced at some point around this time - because the > > MOTU is so particular about its time stamps I wonder whether this has > > something to do with the trouble. It shouldn't, but you never know. > > The cycle timer DLL shouldn't be an issue, but in recent revisions you > can turn it off using a #define. That should revert back to the original > behavior, and for me doesn't seem to influence things for the better. Ok, that seems pretty clear-cut. > I do suspect however that the DLL isn't bug-free yet (I've seen > non-continuous timestamps) I'll keep an eye out for them. > The firewire stack does seem to be a serious blocker for FFADO. It could > be that we're to blame (since freebob works at low latencies), but OTOH > I don't think so. Due to the timestamping it's also not fair to compare > the latencies of both. The new system (for AMDTP compliant devices) > causes the total round-trip latency to be N x period_size (as measured > in jdelay). So it will always be higher than other systems, since it > includes all intermediate (hardware) buffers. What do you mean by "other systems" - firewire audio in other OSes or other audio solutions like PCI cards? > I'm wondering whether it's worthwhile to spend a lot of effort in > getting FFADO at low latencies with the old stack. The API of the new > stack is a lot better for latency, and frankly I'm getting a bit > frustrated of trying to figure out what's happening with the old one. I don't know. On the one hand if we manage low latency with the existing stack things should be even better when we move to the new one. On the other hand, if the API gets in the road perhaps it is too much to ask of the old stack. Having said that I think we ought to at least try to get ffado working again to some extent - at present it is broken for pretty much any latency. > >>> Sure. I wonder whether they just added that little bit of extra overhead > >>> which tipped things over the edge (so to speak). > >> My suspicions at this time are: > >> - a few places that have locks but should be lock-free (I'm going to do > >> RCU for them) > >> - too much debug code in the handlers > >> - no optimization flags: some variables have been replaced by getter > >> functions (e.g. m_1394service => m_parent.get1394service(), which is > >> {return m_1394service;} ). This should not be a big deal since it > >> _should_ come down to the same when optimizing (at least I think so). > >> But without optimizations these are extra function calls. > > > > These are all good candidates, I agree. I suspect that each by themselves > > is not sufficient but together they could cause issues. > except for the RCU stuff, they are rather easy to fix. > We could cache the 1394service reference and others. We could also weed > out the excessive debug statements. That's true, but then again without a verbose setting greater than the default they won't be adding that much overhead, and we're seeing problems under all conditions, not just those with verbose debugging turned on. > >>> I agree with all these points - in particular we can't afford to wait > >>> another 4 months. At the same time we should obviously try hard to minimise > >>> the number of limitations. What date were you thinking of for a release? > >> I would like to have a 'release candidate' (or a very good beta) out by > >> dec 31. > >> > >> The main limitation left at this moment is the latency of the system. > > > > And the regression with MOTU between svn-748 and svn761. :-) > of course :). The only potential issue I see at the moment is that I'll be on leave from 24 Dec to 7 Jan and in that time I'll be at the end of a rather slow dialup line. This in turn has implications for email and svn. I'll try to sort something out but if responses from me over this period seem a little slow you at least know the reason. :-) Regards jonathan |
From: Pieter P. <pi...@jo...> - 2007-12-19 09:25:19
|
Jonathan Woithe wrote: >> The firewire stack does seem to be a serious blocker for FFADO. It could >> be that we're to blame (since freebob works at low latencies), but OTOH >> I don't think so. Due to the timestamping it's also not fair to compare >> the latencies of both. The new system (for AMDTP compliant devices) >> causes the total round-trip latency to be N x period_size (as measured >> in jdelay). So it will always be higher than other systems, since it >> includes all intermediate (hardware) buffers. > > What do you mean by "other systems" - firewire audio in other OSes or other > audio solutions like PCI cards? I'm referring to PCI cards. Those usually have (N x period_size + hardware_buffer) frames of latency. e.g. running jackd with 2 periods of 32 frames on a Delta1010 gives approx 180 frames of effective round trip delay. With fully iec61883/am824 compliant firewire devicea and FFADO running jack with these settings will give exactly 64 frames of latency. Needless to mention that comparing latency between firewire and pci by simply calculating N x period_size is comparing apples to oranges in this case. One side-note is that only DICE devices exhibit this behavior. The others (bebob/fireworks) don't respect the absolute presentation timestamp and add extra latency. ... > > The only potential issue I see at the moment is that I'll be on leave from > 24 Dec to 7 Jan and in that time I'll be at the end of a rather slow dialup > line. This in turn has implications for email and svn. I'll try to sort > something out but if responses from me over this period seem a little slow > you at least know the reason. :-) No problem, Pieter |
From: Jonathan W. <jw...@ph...> - 2008-01-07 03:48:21
|
Hi Pieter I'm back from leave now and have been checking out the ffado svn changes from the past two weeks. In the api cleanup branch of rev 809 the packet-based ports went away. In the MOTU code I notice you've moved the MIDI port stubs into the main period handler by way of the presumedly as yet undefined decodeMotuMidiEventsToPort() and encodePortToMotuMidiEvents() methods (I can't see them in the rev 809 diff). As a result, the old MOTU encodePacketPorts() and decodePacketPorts() methods have been deleted. However, both these deleted methods contained code which, although untested, was a starting point for getting MIDI events into and out of the MOTU. It should have been moved into the decodeMotuMidiEventsToPort() and encodePortToMotuMidiEvents() methods which would of course have defined them. I would have expected that the code in the deleted methods would have been moved to the new methods - just like you did for the Amtdp decodePacketPorts() and encodePacketPorts() code. Is there a fundamental reason why the MOTU code wasn't moved and was instead just dumped? Regards jonathan |
From: Pieter P. <pi...@jo...> - 2008-01-07 09:06:03
|
Jonathan Woithe wrote: > Hi Pieter > > I'm back from leave now and have been checking out the ffado svn changes > from the past two weeks. In the api cleanup branch of rev 809 the > packet-based ports went away. In the MOTU code I notice you've moved the > MIDI port stubs into the main period handler by way of the presumedly as yet > undefined decodeMotuMidiEventsToPort() and encodePortToMotuMidiEvents() > methods (I can't see them in the rev 809 diff). As a result, the old MOTU > encodePacketPorts() and decodePacketPorts() methods have been deleted. > However, both these deleted methods contained code which, although untested, > was a starting point for getting MIDI events into and out of the MOTU. It > should have been moved into the decodeMotuMidiEventsToPort() and > encodePortToMotuMidiEvents() methods which would of course have defined > them. That's correct. > > I would have expected that the code in the deleted methods would have been > moved to the new methods - just like you did for the Amtdp > decodePacketPorts() and encodePacketPorts() code. Is there a fundamental > reason why the MOTU code wasn't moved and was instead just dumped? There is no fundamental reason. I was still planning on re-inserting this code into the motu SP in a later stage. Greets, Pieter |
From: Jonathan W. <jw...@ph...> - 2008-01-07 22:45:10
|
Hi Pieter > > I would have expected that the code in the deleted methods would have been > > moved to the new methods - just like you did for the Amtdp > > decodePacketPorts() and encodePacketPorts() code. Is there a fundamental > > reason why the MOTU code wasn't moved and was instead just dumped? > There is no fundamental reason. I was still planning on re-inserting > this code into the motu SP in a later stage. Good, that's fine then. I'll leave it to you to add it back as your cleanup plans allow. Regards jonathan |
From: Pieter P. <pi...@jo...> - 2008-01-08 09:56:02
|
Jonathan Woithe wrote: >Hi Pieter > > > >>>I would have expected that the code in the deleted methods would have been >>>moved to the new methods - just like you did for the Amtdp >>>decodePacketPorts() and encodePacketPorts() code. Is there a fundamental >>>reason why the MOTU code wasn't moved and was instead just dumped? >>> >>> >>There is no fundamental reason. I was still planning on re-inserting >>this code into the motu SP in a later stage. >> >> > >Good, that's fine then. I'll leave it to you to add it back as your >cleanup plans allow. > > I've been doing some optimizations on the amdtp SP's that can be interesting for the motu too. Especially regarding the muxing and conversion of packets to ports etc, since that seems to be a major performance issue. However I've decided to work on one front only and afterwards do a port to the motu SP. On another thing, I'd like to beta in the very near future, what's the state of the motu code? Greets, Pieter |
From: Jonathan W. <jw...@ph...> - 2008-01-08 22:21:02
|
Hi Pieter > >>>I would have expected that the code in the deleted methods would have been > >>>moved to the new methods - just like you did for the Amtdp > >>>decodePacketPorts() and encodePacketPorts() code. Is there a fundamental > >>>reason why the MOTU code wasn't moved and was instead just dumped? > >>> > >>There is no fundamental reason. I was still planning on re-inserting > >>this code into the motu SP in a later stage. > > > >Good, that's fine then. I'll leave it to you to add it back as your > >cleanup plans allow. > > > I've been doing some optimizations on the amdtp SP's that can be > interesting for the motu too. Especially regarding the muxing and > conversion of packets to ports etc, since that seems to be a major > performance issue. Indeed. One thing I'm trying to work out is an efficient way to encode/decode an array of packed 24 bit integers. The way I currently do this in the MOTU code is effectively to write byte-wise but this is a killer for performance, especially on newer CPUs. I have ideas which, now the whole Christmas thing is finished, I might actually get a chance to experiment with. > However I've decided to work on one front only and afterwards do a port to > the motu SP. Yep, that's fine - pretty much how you did the streaming rework. > On another thing, I'd like to beta in the very near future, what's the > state of the motu code? I'll let you know after I've tested a recent snapshot. I've got a DVD production project on the go at the moment so that's consuming a lot of my time presently. However, I should be able to take a good look at ffado tonight and will advise what I find tomorrow. Regards jonathan |
From: Pieter P. <pi...@jo...> - 2008-01-09 10:26:38
|
Jonathan Woithe wrote: > Hi Pieter > >>>>> I would have expected that the code in the deleted methods would have been >>>>> moved to the new methods - just like you did for the Amtdp >>>>> decodePacketPorts() and encodePacketPorts() code. Is there a fundamental >>>>> reason why the MOTU code wasn't moved and was instead just dumped? >>>>> >>>> There is no fundamental reason. I was still planning on re-inserting >>>> this code into the motu SP in a later stage. >>> Good, that's fine then. I'll leave it to you to add it back as your >>> cleanup plans allow. >>> >> I've been doing some optimizations on the amdtp SP's that can be >> interesting for the motu too. Especially regarding the muxing and >> conversion of packets to ports etc, since that seems to be a major >> performance issue. > > Indeed. One thing I'm trying to work out is an efficient way to > encode/decode an array of packed 24 bit integers. The way I currently do > this in the MOTU code is effectively to write byte-wise but this is a killer > for performance, especially on newer CPUs. I have ideas which, now the > whole Christmas thing is finished, I might actually get a chance to > experiment with. Be sure to take a look at the Amdtp transmit SP (in the api-cleanup branch) when you experiment. I've been doing some performance related things there too. One interesting new aspect might be that I've changed the timestampedbuffer such that it will always call the blockProcessXXX functions with nevents a multiple of 8. This can be very interesting regarding loop unrolling/SSE, although the initial reason for this is different. I'm still trying to figure out a good way to construct a 'cached' data structure that will help optimize the demuxing. But at this moment it's not a real issue. Note that a very big performance hit (for me at least) is the int->float conversion, but that should be solved when compiling with -march=pentium. I'd like to eliminate the 'seconds' field from the timestamps, as it's a rather unnecessary field due to it's timespan. This might be a significant performance optimization since doing so removes (at least) 30% of the work timestamp operations have to do. It also allows us to use 32-bit integers for the timestamp, and IMHO also floats for the timestampedbuffer DLL. What are your thoughts on this? The current trunk and api-cleanup branch still seem to have a startup issue. I didn't see it with the devices I usually test with, but when testing with the (more picky) saffire pro it showed up. Apparently at startup it can happen that we stop sending packets until the system starts (i.e. the device has sent some valid packets). The saffire doesn't like this, and dies. This might be a problem for the motu too. I'm investigating the issue, and it should be solved soon. Greets, Pieter |
From: Jonathan W. <jw...@ph...> - 2008-01-09 22:35:16
|
Hi Pieter > >> I've been doing some optimizations on the amdtp SP's that can be > >> interesting for the motu too. Especially regarding the muxing and > >> conversion of packets to ports etc, since that seems to be a major > >> performance issue. > > > > Indeed. One thing I'm trying to work out is an efficient way to > > encode/decode an array of packed 24 bit integers. The way I currently do > > this in the MOTU code is effectively to write byte-wise but this is a killer > > for performance, especially on newer CPUs. I have ideas which, now the > > whole Christmas thing is finished, I might actually get a chance to > > experiment with. > > Be sure to take a look at the Amdtp transmit SP (in the api-cleanup > branch) when you experiment. Initially I'll be doing some out-of-tree tests since it's easier to measure performance. What's your plan for merging your api-cleanup branch back to main? > Note that a very big performance hit (for me at least) is the int->float > conversion, but that should be solved when compiling with -march=pentium. Yes, it always is on Pentiums. It's to do with the way gcc codes int-float conversions - it does it in a way which causes a pipeline stall on the FPU. Check out http://mega-nerd.com/FPcast/ for the details of the problem. At the end of this document are links to header files which implement the ideas contained therein. A few months ago I tested the theory in ffado with a subset of the MOTU code and found that the implementation of these ideas did result in a drop in the CPU load required by ffado. Messing with these ideas inside the MOTU code is one of the things I want to do in the near future since its a relatively easy way of getting a potentially large efficiency improvement. > I'd like to eliminate the 'seconds' field from the timestamps, as it's a > rather unnecessary field due to it's timespan. This might be a > significant performance optimization since doing so removes (at least) > 30% of the work timestamp operations have to do. It also allows us to > use 32-bit integers for the timestamp, and IMHO also floats for the > timestampedbuffer DLL. What are your thoughts on this? I don't need the seconds field for the MOTU - in fact the MOTU does not send or receive a seconds field in its pseudo-timestamp fields, so in order to utilise the current DLL I have to synthesise the seconds field within the MOTU code. Unless there's something I've missed I don't have a problem with the seconds field going away. Moving from double to float for the timestampedbuffer DLL would improve performance I would expect, especially on 32 bit CPUs. However, we have to be careful to ensure that we really do have sufficient resolution with a float since some interfaces (eg: the MOTU) really cannot work without it. Having a look at my initial notes on the subject my immediate reaction is that even without the seconds field a float is unlikely to provide sufficient resolution to keep picky interfaces like the MOTU happy. After dropping the seconds field the maximum count in the DLL accumulators will be 24576000. Thus we consume 8 significant figures for the units portion of the DLL timestamp value. Experimentation has shown that the MOTU requires at least 2 decimal places of precision (and preferably more) to ensure the timestamps don't drift due to round-off effects. A float has no more than 9 significant digits, which would mean that for at least half a second the DLL will only be capable of reporting (and keeping track of) at most one decimal place in its timestamps. This is almost certainly insufficient for correct operation of the MOTU based on prior experience. Having said all that I think it's infinitely preferable to get rid of the use of double in the timestamped buffer - as I mentioned at the time I made the change to double in July 2007. However, if this is to be done we'll have to come up with a clever way of preserving sufficient precision for interfaces like the MOTU - a float by itself is unlikely to be enough, even without the seconds field. > The current trunk and api-cleanup branch still seem to have a startup > issue. I didn't see it with the devices I usually test with, but when > testing with the (more picky) saffire pro it showed up. Apparently at > startup it can happen that we stop sending packets until the system > starts (i.e. the device has sent some valid packets). The saffire > doesn't like this, and dies. This might be a problem for the motu too. > I'm investigating the issue, and it should be solved soon. No problem. Under alternative operating systems I have confirmed that the OS in fact does not start sending packets to the device until some time after streaming is started. It seems to me that the software does this to allow the transmit stream to lock to the timing provided by the receive stream before attempting transmission. It's therefore likely that the MOTU may in fact tolerate the above stream interruption but of course testing is the only way to confirm or deny this. Note I didn't get to the testing overnight because something which was to occur tonight got moved to last night at the last minute. Therefore I should be able to do something tonight instead. Regards jonathan |
From: Jonathan W. <jw...@ph...> - 2008-01-10 23:13:46
|
Hi Pieter As promised, here is a report on how svn rev 828 went with my MOTU last night. In summary: it's mixed. FFADO version: svn 828 Kernel: 2.6.23.9 with "low latency desktop" setting JACK: 0.107.5 I compiled ffado using scons ENABLE_FIREWORKS=no During the compilation I received the following error: sh: xdg-desktop-menu: command not found scons: *** [support/mixer/.ffado.org-ffadomixer.desktop] Error 127 Looking at support/mixer/SConstruct it seems this program should only be called if XDG_TOOLS is defined, and that in turn is checked for in the top-level SConstruct file. On my system scons is correctly reporting that xdg-desktop-menu doesn't exist: Checking wether 'xdg-desktop-menu --help' executes (cached) no It is therefore a mystery as to why support/mixer/SConstruct is still attempting to call it. Someone with more mastery over scons will have to take a look at this. What precisely is xdg-desktop-menu meant to do, anyway? To get around the problem for now I simply commented out the xdg-desktop-menu call in support/mixer/SConstruct. I started jackd using jackd -R -P60 -dfirewire -r 44100 -p1024 -n4 Xwindows was not active while running these tests. For about a second or so after audio started flowing to the interface I heard tell-tale signs of minor sync issues; presumedly the DLLs were still stabilising. The errors were not sufficient to upset the MOTU though, and after about a second of these intermittant glitches they stopped occuring. jackd then ran for about 25 minutes without further problems. I stopped it at that point to test other things (see below). During its run I was compiling jackd and ffado and this activity didn't appear to upset things. Of course X wasn't running - that may well change things. There were a couple of issues noted, however. The first is that CPU consumption by jackd/ffado has skyrocketed to some 65% on my 2 GHz CPU. This is *much* higher than I've seen with any previous freebob/ffado revision - in the past I've been seeing between 15% and 20%. Obviously there's been a dramatic change somewhere which has caused the CPU usage to rise sharply. It would be good to work out what it was and do something to bring it back down to a more reasonable level. The other problem was during shutdown - after pressing Ctrl-C on the jackd process jackd responded with jack main caught signal 2 and then sat around doing very little for about 10 seconds, after which it exitted after displaying jackd watchdog: timeout - killing jackd Killed If a second Ctrl-C is pressed before the watchdog kicks in jackd shows received signal 2 during shutdown (ignored) Regardless of which of these scenarios is considered, device shutdown is clearly not as clean as it has been in the past - the high-pitched squeal has reappeared which means the streaming shutdown is no longer to the MOTU's liking. This is a regression from earlier revisions; for example, svn761 (I think) was fine on MOTU shutdown. Something is obviously amiss with shutdown. I'll have to take a closer look to see if it's a MOTU-specific thing or related more to the underlying infrastructure. Finally in an attempt to work out what the CPU hog was I compiled jackd with "-pg" to emit profiling information. This worked but as ffado was not also compiled with "-pg" the profiling info was limited to jackd functions. I then hacked "-pg" into CFLAGS and CCFLAGS in ffado's top-level SConstruct and compiled after defining LDFLAGS to be "-pg" in my environment (although I'm not sure whether scons respects this). Unfortunately, with the resulting libffado in place jackd would segfault when loading the driver. I did not have time to pursue this any further last night. At some point over the next few days I hope to do longer and more extensive stability tests to gauge where we're at with MOTU usability. So that's about it at the moment. Before going beta I think we really need to work out why the CPU usage has risen so dramatically. Fixing the shutdown regression is also important. Regards jonathan |
From: Pieter P. <pi...@jo...> - 2008-01-11 09:47:45
|
Jonathan Woithe wrote: > Hi Pieter > > As promised, here is a report on how svn rev 828 went with my MOTU last > night. In summary: it's mixed. > > FFADO version: svn 828 > Kernel: 2.6.23.9 with "low latency desktop" setting > JACK: 0.107.5 > > I compiled ffado using > > scons ENABLE_FIREWORKS=no > > During the compilation I received the following error: > > sh: xdg-desktop-menu: command not found > scons: *** [support/mixer/.ffado.org-ffadomixer.desktop] Error 127 > > Looking at support/mixer/SConstruct it seems this program should only be > called if XDG_TOOLS is defined, and that in turn is checked for in the > top-level SConstruct file. On my system scons is correctly reporting that > xdg-desktop-menu doesn't exist: > > Checking wether 'xdg-desktop-menu --help' executes (cached) no > > It is therefore a mystery as to why support/mixer/SConstruct is still > attempting to call it. Someone with more mastery over scons will have to > take a look at this. What precisely is xdg-desktop-menu meant to do, > anyway? > > To get around the problem for now I simply commented out the > xdg-desktop-menu call in support/mixer/SConstruct. > > I started jackd using > > jackd -R -P60 -dfirewire -r 44100 -p1024 -n4 > > Xwindows was not active while running these tests. > > For about a second or so after audio started flowing to the interface I > heard tell-tale signs of minor sync issues; presumedly the DLLs were still > stabilising. The errors were not sufficient to upset the MOTU though, and > after about a second of these intermittant glitches they stopped occuring. > jackd then ran for about 25 minutes without further problems. I stopped it > at that point to test other things (see below). During its run I was > compiling jackd and ffado and this activity didn't appear to upset things. > Of course X wasn't running - that may well change things. That's good news. > > There were a couple of issues noted, however. The first is that CPU > consumption by jackd/ffado has skyrocketed to some 65% on my 2 GHz CPU. > This is *much* higher than I've seen with any previous freebob/ffado > revision - in the past I've been seeing between 15% and 20%. Obviously > there's been a dramatic change somewhere which has caused the CPU usage to > rise sharply. It would be good to work out what it was and do something to > bring it back down to a more reasonable level. I'm working on it, I know what the major issues are. It should be better when using the latest revision. Functionality > > The other problem was during shutdown - after pressing Ctrl-C on the jackd > process jackd responded with > > jack main caught signal 2 > > and then sat around doing very little for about 10 seconds, after which > it exitted after displaying > > jackd watchdog: timeout - killing jackd > Killed > > If a second Ctrl-C is pressed before the watchdog kicks in jackd shows > > received signal 2 during shutdown (ignored) Known issue, working on it. > > Regardless of which of these scenarios is considered, device shutdown is > clearly not as clean as it has been in the past - the high-pitched squeal > has reappeared which means the streaming shutdown is no longer to the MOTU's > liking. This is a regression from earlier revisions; for example, svn761 (I > think) was fine on MOTU shutdown. > > Something is obviously amiss with shutdown. I'll have to take a closer look > to see if it's a MOTU-specific thing or related more to the underlying > infrastructure. What you would want is to make sure the DryRunning phase outputs 'silent' packets. But for the real shutdown things might be different. Normally the system is such that there are only either silent packets or jackd-based packets. > > Finally in an attempt to work out what the CPU hog was I compiled jackd with > "-pg" to emit profiling information. This worked but as ffado was not also > compiled with "-pg" the profiling info was limited to jackd functions. I > then hacked "-pg" into CFLAGS and CCFLAGS in ffado's top-level SConstruct > and compiled after defining LDFLAGS to be "-pg" in my environment (although > I'm not sure whether scons respects this). Unfortunately, with the > resulting libffado in place jackd would segfault when loading the driver. I > did not have time to pursue this any further last night. > > At some point over the next few days I hope to do longer and more extensive > stability tests to gauge where we're at with MOTU usability. > > So that's about it at the moment. Before going beta I think we really need > to work out why the CPU usage has risen so dramatically. Fixing the > shutdown regression is also important. Please focus on the functionality (shutdown) first. The CPU usage should already be improved with merge of the api-cleanup branch, and the shutdown hang/segfaults will be fixed too. Greets, Pieter |
From: Jonathan W. <jw...@ph...> - 2008-01-13 22:29:55
|
Hi Pieter > > There were a couple of issues noted, however. The first is that CPU > > consumption by jackd/ffado has skyrocketed to some 65% on my 2 GHz CPU. > > This is *much* higher than I've seen with any previous freebob/ffado > > revision - in the past I've been seeing between 15% and 20%. Obviously > > there's been a dramatic change somewhere which has caused the CPU usage to > > rise sharply. It would be good to work out what it was and do something to > > bring it back down to a more reasonable level. > I'm working on it, I know what the major issues are. It should be better > when using the latest revision. Functionality Right. I'll give it a go. > > Regardless of which of these scenarios is considered, device shutdown is > > clearly not as clean as it has been in the past - the high-pitched squeal > > has reappeared which means the streaming shutdown is no longer to the MOTU's > > liking. This is a regression from earlier revisions; for example, svn761 (I > > think) was fine on MOTU shutdown. > > > > Something is obviously amiss with shutdown. I'll have to take a closer look > > to see if it's a MOTU-specific thing or related more to the underlying > > infrastructure. > What you would want is to make sure the DryRunning phase outputs > 'silent' packets. But for the real shutdown things might be different. > Normally the system is such that there are only either silent packets or > jackd-based packets. I'll check this out. > > So that's about it at the moment. Before going beta I think we really need > > to work out why the CPU usage has risen so dramatically. Fixing the > > shutdown regression is also important. > Please focus on the functionality (shutdown) first. The CPU usage should > already be improved with merge of the api-cleanup branch, and the > shutdown hang/segfaults will be fixed too. Ok. Over the weekend I attempted to test svn 833 which I grabbed just before leaving work on Friday. Unfortunately I forgot to also grab an updated jack revision which it seems is needed now the API cleanup has been merged (svn 1070 didn't compile against libffado 833). I'll get this today and test tonight. Regards jonathan |
From: Jonathan W. <jw...@ph...> - 2008-01-14 22:31:49
|
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. 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. 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. 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. Regards jonathan |
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 |
From: Jonathan W. <jw...@ph...> - 2008-01-14 23:01:52
|
Hi Pieter > > 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. Oh yes, there's that issue - I'd forgotten about that. I'll give this a go. > > 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. Just to clarify why I'm interested in this: the MOTU requires a number of zeroed audio packets be sent to it during shutdown. I would expect that "silence" packets - audio data packets witht he data set to zero - would be the way to achieve this. I already know that "empty" data packets are not sufficient for the MOTU on closedown - it wants zeroed audio data. Even with zeroed audio packets in the equation I still can't see exactly where the Motu code would call them. I suspect it might be something taken care of at a higher level since the device specific code really only implements tasks now - the process is taken care of at other levels. > > 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. Sure. I'll await your thoughts. Regards jonathan |
From: Pieter P. <pi...@jo...> - 2008-01-15 08:55:44
|
Jonathan Woithe wrote: > Hi Pieter > >>> 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. > > Oh yes, there's that issue - I'd forgotten about that. I'll give this a go. > >>> 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. > > Just to clarify why I'm interested in this: the MOTU requires a number of > zeroed audio packets be sent to it during shutdown. I would expect that > "silence" packets - audio data packets witht he data set to zero - would be > the way to achieve this. I already know that "empty" data packets are not > sufficient for the MOTU on closedown - it wants zeroed audio data. > > Even with zeroed audio packets in the equation I still can't see exactly > where the Motu code would call them. I suspect it might be something taken > care of at a higher level since the device specific code really only > implements tasks now - the process is taken care of at other levels. Does the MOTU need zeroed packets as absolute last packets or would the following also do: - send audio packets - shutdown requested - send a set of zeroed packets - send 'empty' packets If so, things would be much easier since I could send zeroed packets in the WaitingForStreamDisable state, that takes approx 200 cycles (customizable).. Greets, Pieter |
From: Jonathan W. <jw...@ph...> - 2008-01-15 23:06:26
|
Hi Pieter > >>> 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. > > > > Just to clarify why I'm interested in this: the MOTU requires a number of > > zeroed audio packets be sent to it during shutdown. I would expect that > > "silence" packets - audio data packets witht he data set to zero - would be > > the way to achieve this. I already know that "empty" data packets are not > > sufficient for the MOTU on closedown - it wants zeroed audio data. > > > > Even with zeroed audio packets in the equation I still can't see exactly > > where the Motu code would call them. I suspect it might be something taken > > care of at a higher level since the device specific code really only > > implements tasks now - the process is taken care of at other levels. > > Does the MOTU need zeroed packets as absolute last packets or would the > following also do: > - send audio packets > - shutdown requested > - send a set of zeroed packets > - send 'empty' packets > > If so, things would be much easier since I could send zeroed packets in > the WaitingForStreamDisable state, that takes approx 200 cycles > (customizable).. So long as zeroed audio packets are the last *audio* packets seen by the device that is sufficient. Therefore, if only empty packets follow the zeroed packets I think we'll be right. Precisely how many zeroed packets are needed may have to be determined experimentally but based on earlier work I suspect that 200 cycles would be sufficient. In summary, the process outlined by yourself should be fine for the MOTU. I should note that apart from the packets containing zero audio data these zeroed packets should in every other respect be valid audio packets - in particular the sample timestamps sent to the device must be right. Regards jonathan |
From: Pieter P. <pi...@jo...> - 2008-01-16 10:28:42
|
Jonathan Woithe wrote: > Hi Pieter > >>>>> 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. >>> Just to clarify why I'm interested in this: the MOTU requires a number of >>> zeroed audio packets be sent to it during shutdown. I would expect that >>> "silence" packets - audio data packets witht he data set to zero - would be >>> the way to achieve this. I already know that "empty" data packets are not >>> sufficient for the MOTU on closedown - it wants zeroed audio data. >>> >>> Even with zeroed audio packets in the equation I still can't see exactly >>> where the Motu code would call them. I suspect it might be something taken >>> care of at a higher level since the device specific code really only >>> implements tasks now - the process is taken care of at other levels. >> Does the MOTU need zeroed packets as absolute last packets or would the >> following also do: >> - send audio packets >> - shutdown requested >> - send a set of zeroed packets >> - send 'empty' packets >> >> If so, things would be much easier since I could send zeroed packets in >> the WaitingForStreamDisable state, that takes approx 200 cycles >> (customizable).. > > So long as zeroed audio packets are the last *audio* packets seen by the > device that is sufficient. Therefore, if only empty packets follow the > zeroed packets I think we'll be right. Precisely how many zeroed packets > are needed may have to be determined experimentally but based on earlier > work I suspect that 200 cycles would be sufficient. > > In summary, the process outlined by yourself should be fine for the MOTU. That's good news. > > I should note that apart from the packets containing zero audio data these > zeroed packets should in every other respect be valid audio packets - in > particular the sample timestamps sent to the device must be right. It should be possible to do so, since we can re-use the normal packet header generation, but simply use a 'empty payload' data generation function when doing shutdown. That would be the easiest thing to implement. I'll try to implement it over the next few days. Greets, Pieter |
From: Jonathan W. <jw...@ph...> - 2008-01-16 22:35:05
|
Hi Pieter > > I should note that apart from the packets containing zero audio data these > > zeroed packets should in every other respect be valid audio packets - in > > particular the sample timestamps sent to the device must be right. > > It should be possible to do so, since we can re-use the normal packet > header generation, but simply use a 'empty payload' data generation > function when doing shutdown. That would be the easiest thing to > implement. I'll try to implement it over the next few days. I shall await it with interest and revisit the shutdown issues when it appears. FYI, the way I used to implement this (before the latest streaming changes) was to have a shutdown flag set in the stream processor when shutdown was in progress. After reading from the ports as normal (to prevent buffer overflows) the standard packet generator checked for this flag and if it were set just did a memset() on the packet to set all the data to zero. We also have to clarify terminology so I don't get confused. To me, a normal packet is one which contains actual audio data. An empty packet is an iso packet which contains just the header with no audio data at all. A silence packet is a normal audio data packet but with all the audio data set to zero. That's how I would interpret the three types of packets we seem to have at the moment (although as previously mentioned there may not be a practical difference between empty and silence currently). I'm not fussed if we change the terminology but either way I'd like to know what each of these terms really refers to. If we use the above terminology I think "'empty payload' data generation function" mentioned above should really be "'silence payload' data generation function" unless of course you are referring to later in the shutdown process. Regards jonathan |