[QLab] Dropouts, Error -32767 and discontinuous timestamps; Qlab 2.3.4 on a Mac Mini through a RME FF800
Matt
I'm having random dropouts and hiccups playing a non-intensive show
through the following system:
QLab v2.3.4, Pro Bundle licence;
Mac Mini A1283 model, twin HDDs (one apps, one content), 8GB RAM, OS X
10.6.2;
RME FireFace800 interface connected (via a Kramer FW800 hub and a
Lacie rugged HDD) using FW800.
RME driver and firmware are up to date.
Audio sometimes mutes for a split-second, or hiccups and skips. In the
console log I see these messages:
02/06/2011 17:13:50 QLab[676] WARNING: (null) had discontinuous
timestamps. Re-basing timeline. inTimeStamp->mSampleTime = 0,
_lastSample = 316569095
02/06/2011 17:13:50 QLab[676] (null) Re-basing:
_firstHostTime = 29329894920399, _firstSample = 0, _firstRawSample =
315644776
02/06/2011 17:13:50 QLab[676] WARNING: (null) had discontinuous
timestamps. Re-basing timeline. inTimeStamp->mSampleTime = 0,
_lastSample = 316424711
02/06/2011 17:13:50 QLab[676] (null) Re-basing:
_firstHostTime = 29330173560133, _firstSample = 0, _firstRawSample = 0
followed by eight pairs of these:
02/06/2011 17:13:51 QLab[676] ERROR: -32767 [Ä@f] FFSound.m: 1709
02/06/2011 17:13:51 QLab[676] ERROR: -32767 [Ä@f] FFSound.m: 1723
in turn followed by a larger number of these (all identical):
02/06/2011 17:14:15 QLab[676] ERROR: (null) said its max buffer size
in frames was zero.
I am only using two output channels, and the number of simultaneous
cues is not large (less than six).
The Kramer hub and the Lacie HDD are there to solve a known issue with
the Lucent FireWire hardware in the Mac Mini (for more information,
see this thread on the RME forum: http://www.rme-audio.de/forum/viewtopic.php?id=974
).
My only thought is that I may be exceeding the maximum allowed length
of FireWire cable?
Any advice and thoughts greatly appreciated!
Many thanks,
Matt
________________________________________________________
WHEN REPLYING, PLEASE QUOTE ONLY WHAT YOU NEED. Thanks!
Change your preferences or unsubscribe here:
http://lists.figure53.com/listinfo.cgi/qlab-figure53.com
Follow Figure 53 on Twitter here: http://twitter.com/Figure53
Christopher Ashworth
Thanks for the thorough report.
A couple of thoughts and comments:
These last two messages are taking place when QLab is querying level values (post average and post peak hold) on the audio matrix of at least one cue.
> in turn followed by a larger number of these (all identical):
>
> 02/06/2011 17:14:15 QLab[676] ERROR: (null) said its max buffer size
> in frames was zero.
The null's are certainly concerning; it seems like the audio device could be "disappearing" from QLab's perspective. Are there any "audioDeviceDidDie" messages in there?
Keith Smith
On 2 Jun 2011, at 19:43, Matt wrote:
> RME FireFace800 interface connected (via a Kramer FW800 hub and a
> Lacie rugged HDD) using FW800.
Have you told OSX not to let the the drives go to sleep?
I haven't used a Kramer hub, but I have read a few reports of people having problems with them, for example:
http://hotusbfirehubbox.blogspot.com/2011/04/kramer-tools-vs-30fw-hub-desktop.html
> The Kramer hub and the Lacie HDD are there to solve a known issue with
> the Lucent FireWire hardware in the Mac Mini (for more information,
> see this thread on the RME forum: http://www.rme-audio.de/forum/viewtopic.php?id=974
> ).
I note that the above thread is from 2007 and is specifically referring to that generation of iMac's. The A1283 is pretty new, are you sure it has the same problem? The thread at http://www.rme-audio.de/forum/viewtopic.php?id=9369 seems to suggest that it isn't a problem any more.
Regards,
Keith.
Matt
Chris, I don't see any 'DidDie' messages but I'll look again.
Interesting about QLab querying levels; can you elaborate on this? If
the levels are set by the cue then is QLab querying itself? [aside:
existential software crisis humour...:) ]
Keith, Drives are set to not sleep. The Kramer hub is something I keep
looking at. It uses an old version of the Texas TSB81BA3 firewire
hardware, which is reported to have some issues and has since been
superseded (see this page: http://en.souvr.com/CaseStudy/200909/2781.html
). I could try a Lindy hub (more recent hardware) but that will be a
few days coming.
Tomorrow I'll try without the hub at all (ie direct from Mac to
FireFace) for the purposes of elimination. Using ioreg in Terminal
suggests that the Lucent hardware revision is v7, which according to
RME is trouble-free. So would the hub reintroduce that problem
somehow?
Kind regards,
Matt
On Jun 2, 8:25 pm, Keith Smith <keith.sm...@keiths-place.com> wrote:
> On 2 Jun 2011, at 19:43, Matt wrote:
>
> > RME FireFace800 interface connected (via a Kramer FW800 hub and a
> > Lacie rugged HDD) using FW800.
>
> Have you told OSX not to let the the drives go to sleep?
>
> I haven't used a Kramer hub, but I have read a few reports of people having problems with them, for example:http://hotusbfirehubbox.blogspot.com/2011/04/kramer-tools-vs-30fw-hub...
>
> > The Kramer hub and the Lacie HDD are there to solve a known issue with
> > the Lucent FireWire hardware in the Mac Mini (for more information,
> > see this thread on the RME forum:http://www.rme-audio.de/forum/viewtopic.php?id=974
> > ).
>
> I note that the above thread is from 2007 and is specifically referring to that generation of iMac's. The A1283 is pretty new, are you sure it has the same problem? The thread athttp://www.rme-audio.de/forum/viewtopic.php?id=9369seems to suggest that it isn't a problem any more.
>
> Regards,
> Keith.
>
> smime.p7s
> 4KViewDownload
Christopher Ashworth
On Jun 2, 2011, at 3:46 PM, Matt wrote:
>
> Chris, I don't see any 'DidDie' messages but I'll look again.
> Interesting about QLab querying levels; can you elaborate on this? If
> the levels are set by the cue then is QLab querying itself? [aside:
> existential software crisis humour...:) ]
Heh -- sure, I can elaborate:
These are the levels of the actual audio signal flowing through the matrix, so this is what is used when drawing the volume levels inside the fader sliders.
It's essentially a side-effect of something having gone wrong prior to the moment QLab went to ask what the signal levels were. When it did, it hit errors because something deeper has gone wrong.
-C
Matt
'AudioDeviceDidDie: (null)' messages, which occur immediately before
the 'discontinuous timestamps' messages.
We're running at 400 speed now, albeit still via a FW800 hub. We
changed a cable this morning, and up to a few minutes ago all was
well, but now the problem is back.
I also notice that the FireFace800 is extremely hot, almost too hot to
keep my hand on the bottom of its case.
So, is the FireFace800 overheating and misbehaving? The computer rack
is undisturbed, so no cables are moving.
Matt
Christopher Ashworth
Thanks for the updates!
Good information; so it does look like the device is getting disconnected in some manner, which is leading to the cascade of errors before QLab is able to reconnect to the device.
Both the heat and the hub would be things I'd attempt to eliminate if possible. I know the hub is used to work around a known issue, so that may be the harder one. (Are there any other audio devices you could test with, even just the built-in output?)
Overheating devices can also lead to strange behavior, so if cooling that down would also be worth trying.
-C
On Jun 3, 2011, at 3:00 PM, Matt wrote:
> I looked at the Console logs again. There are indeed four
> 'AudioDeviceDidDie: (null)' messages, which occur immediately before
> the 'discontinuous timestamps' messages.
>
> We're running at 400 speed now, albeit still via a FW800 hub. We
> changed a cable this morning, and up to a few minutes ago all was
> well, but now the problem is back.
>
> I also notice that the FireFace800 is extremely hot, almost too hot to
> keep my hand on the bottom of its case.
>
> So, is the FireFace800 overheating and misbehaving? The computer rack
> is undisturbed, so no cables are moving.
>
> Matt
________________________________________________________
Rich Walsh
> I looked at the Console logs again. There are indeed four
> 'AudioDeviceDidDie: (null)' messages, which occur immediately before
> the 'discontinuous timestamps' messages.
>
> We're running at 400 speed now, albeit still via a FW800 hub. We
> changed a cable this morning, and up to a few minutes ago all was
> well, but now the problem is back.
>
> I also notice that the FireFace800 is extremely hot, almost too hot to
> keep my hand on the bottom of its case.
>
> So, is the FireFace800 overheating and misbehaving? The computer rack
> is undisturbed, so no cables are moving.
In my experience, ALL RME kit runs hot. I built 4 systems with Mac minis from 2009 and RME Fireface 800s; they all have a vent panel above the RME. I completely ignored all that rubbish on the RME forums about FireWire - even when I could not get the RME to work with SFX on the Windows side of the Macs (what a waste of time that exercise was!); eventually a new Windows driver came along that worked properly. I fear those kind of forums which seem to be populated by a lot of very verbal people who give the impression of understanding very little about what they are saying. RME support is very good here in the UK: I found it more productive to speak directly to them!
I left these systems with Mac OS X 10.6.2 & RME driver v2.63; they have worked perfectly for over a year. I do see this message in my Console whenever I open QLab:
ERROR: -10851 [ù’ˇˇ] FFSoundDevice.m: 363
This is on my laptop, and I don't know if having a Fireface attached makes any difference.
It is worth noting that even though the Fireface 800 has 3 FW ports, it does not support "FW through" - in that you can't connect it between a Mac and a hard drive. It amazed me that this did not work, and I confirmed it with RME themselves. Never did figure out why it has two FW800 ports; perhaps they only work with other Firefaces?
I would ditch the hub and the external drive and test the system with a FW800 cable between the Mac and the Fireface - after I'd checked I did actually have the latest driver that was supported for that version of the OS. I'd try reflashing the firmware too, as I have a vague memory of it not taking properly on one of the units...
My money's on the hub being the issue...
Rich
Matt
Thank you Chris and Rich. I agree with you about the RME forum; much
noise and little music.
Amazing news that the FW800 ports are not thru'd! But that DOES
explain an issue I had in a previous show with an external drive
neither powering nor mounting.
So, here's what I'll do: go direct to the FireFace using a 800-400
cable. If that is good, then I'll reintroduce the FW800 hub but still
using the 400 in on the FireFace. While I'm at it I'll shorten all the
FW links in the rack; I can probably lose a couple of metres of bus
length.
Cooling the FireFace is more interesting. The system is built into a
4U double-ended shock rack and the only possible vent space is the
remote power-button panel above the FireFace. I'll make a new one of
these using a 1U vent (it'll be fun drilling that!). I could look at
force-cooling the FireFace but that invariably gets noisy.
I'll report in due course.
Matt
*
rack mount it on top / bottom of other heatsinks, I think it's quite
possible it's causing an issue.
Fortunately, removing it from the rack & testing should reveal the answer.
Never be afraid to pull a device out of the rack...
Keep us posted.
ra byn (robin)
On Fri, June 3, 2011 2:37 pm, Matt wrote:
> Cooling the FireFace is more interesting. The system is built into a
> 4U double-ended shock rack and the only possible vent space is the
> remote power-button panel above the FireFace. I'll make a new one of
> these using a 1U vent (it'll be fun drilling that!). I could look at
> force-cooling the FireFace but that invariably gets noisy.
Andy Leviss
> I own a FF800 & it runs hot even sitting by itself on the desk. If you
> rack mount it on top / bottom of other heatsinks, I think it's quite
> possible it's causing an issue.
Ah, but physics says otherwise. Spacing out hot devices in a rack is
terribly inefficient. When heatsinks can couple together, they cool
more efficiently. One of the amp manufacturers in fact is very
explicit that when building amp racks where heat is an issue, you
should tightpack the amps together, and NOT space them out, for just
this reason. (I want to say it's either Crest or Crown, but not
certain.)
--andy
*
forced air cooling & so I believe the reason to "tight pack" them is to
make sure the air pulls thru them without just circulating right back
around the front again. Maybe QSC.
There is also the benefit of having all the amps sitting on each other &
so one supports the next & so on. Where as leaving space between them
would mean the rear should be supported.
Most modern amps also have a thermally controlled fan / fans so as it gets
hotter more cooling is provided, etc...
On the other hand (3) hot running non cooled devices sandwiched in a rack
with no fans are just going to stay hot. Especially if it they're in a
soft rack where the fabric acts like an insulator at the top / bottom.
Another case in point:
I have (3) Ashly VCA units. The signal lights on the 2 newer ones (SMT
based) come on randomly & stay on when there isn't any signal present
because the box gets too hot sandwiched between other devices in the rack.
If I leave the device out on the table, there are no signal light issues.
When I stick them back in the rack with something on top & bottom, the
lights come back on. This is true even if the devices above / below aren't
very hot themselves.
To Ashly's credit came up with a fix (some resistors) & upgraded both of
my newer units under warranty but sadly, I just discovered that when I
mount them back in a rack without space above & below, the signal lights
come back on randomly. A bummer because extra rack spaces don't grow on
trees & my rack is full.
Then there is Tascam who vents a 1 RU device & then sticks a sticker on it
saying, "must leave space above the device or else".
My Tascam SSCDR1 is one such unit. I can understand vents on tube based
rack devices but on a solid state device???
ra byn
On Fri, June 3, 2011 3:30 pm, Andy Leviss wrote:
> On Fri, Jun 3, 2011 at 4:19 PM, * <ra...@rabyn.com> wrote:
>> I own a FF800 & it runs hot even sitting by itself on the desk. If you
>> rack mount it on top / bottom of other heatsinks, I think it's quite
>> possible it's causing an issue.
>
> Ah, but physics says otherwise. Spacing out hot devices in a rack is
> terribly inefficient. When heatsinks can couple together, they cool
> more efficiently. One of the amp manufacturers in fact is very
> explicit that when building amp racks where heat is an issue, you
> should tightpack the amps together, and NOT space them out, for just
> this reason. (I want to say it's either Crest or Crown, but not
> certain.)
Rich Walsh
> On Fri, Jun 3, 2011 at 4:19 PM, * <ra...@rabyn.com> wrote:
>> I own a FF800 & it runs hot even sitting by itself on the desk. If you
>> rack mount it on top / bottom of other heatsinks, I think it's quite
>> possible it's causing an issue.
>
> Ah, but physics says otherwise. Spacing out hot devices in a rack is
> terribly inefficient. When heatsinks can couple together, they cool
> more efficiently. One of the amp manufacturers in fact is very
> explicit that when building amp racks where heat is an issue, you
> should tightpack the amps together, and NOT space them out, for just
> this reason. (I want to say it's either Crest or Crown, but not
> certain.)
I think it was Crown:
http://www.crownaudio.com/kb/entry/22/
It only applies to fan-cooled - not convection-cooled - according to that entry.
PowerSoft say the same thing (Q12):
http://www.powersoft.it/faq_list.php?use_in=83&id_menu=334&obj=5
Having said that, I do have a vague recollection of a manufacturer who designed their convection-cooled amplifiers to couple together, but I can't remember who...
It doesn't make sense to me as a general principal though: if a device is expecting to radiate heat through its entire surface area to air at a much lower temperature, that mechanism is going to break down if it's attempting to lose heat at the same rate to a body that is at a similar temperature to itself (unless the other body is markedly more efficient at radiating away through its still-exposed surfaces). Admittedly a good contact with another metal case will increase conduction, but the second device is going to need to radiate the heat instead. Considered as a whole, the two coupled units are now trying to lose heat at their combined rate through a much reduced cumulative surface area. If one is hot and the other is not, and the cooler one has better fins than the hotter one then bonus - but on the whole that may not always be the case. When mounting many identical devices it does make some kind of sense to couple them well and share the generated heat between them to m
ake better average use of the cooling fins, but I reckon that only applies when the units are essentially identical. I certainly wouldn't put two Firefaces next to each other, unless I was planning on frying eggs!
I came across this, which looks interesting:
http://middleatlantic.com/pdf/ThermalManagement.pdf
Rich
Matt
Well, good news!
I ran a 800-400 cable direct from the Mac Mini to the FireFace80, and
temporarily deracked the button panel above the FireFace to give it
breathing space. Result: no console errors and no audible hiccups!
So now I just need to rework the rack to make these new features
permament. Losing the hubs isn't an issue, as clearly I didn't need
them anyway. I still need a FW patch; there is a second Mac in the
rack as a running spare.
Many thanks to all for the fine advice!
Matt
Jeremy Lee
Jeremy Lee
- A thumb is a terrible speller. Please forgive my trespasses.
On Jun 3, 2011, at 3:21 PM, Rich Walsh <rich...@mac.com> wrote:
>
> It is worth noting that even though the Fireface 800 has 3 FW ports, it does not support "FW through" -
Rich Walsh
> Is that true? I do this all the time with my FF400. I would have thought this would work. You definitely can daisy chain FF800 units...
>
> Jeremy Lee
> - A thumb is a terrible speller. Please forgive my trespasses.
>
> On Jun 3, 2011, at 3:21 PM, Rich Walsh <rich...@mac.com> wrote:
>
>> It is worth noting that even though the Fireface 800 has 3 FW ports, it does not support "FW through" -
I tested it quite thoroughly at the time: in our rehearsal system racks we had a breakout panel from the PC so that we could add extra devices beyond what was in the rack. When I changed the PCs to Mac minis the only way to get the FW connection was via the FF800, and it didn't work. As I was in touch with RME at the time about the flaky Windows drivers I asked about this and was told that it was not supported. I'm not able to test again at the moment as I'm away from the NT until at least October. I bought combined USB/FW hubs to go in those racks (we'd used up all the USB ports too), but I didn't get round to installing them.
I was testing with a bus-powered drive (the master clone), so maybe it's only bus-powering that doesn't work? This section of the manual would suggest that it _should_ work in some degree:
"When using all channels of more than one Fireface 800, a FireWire 800 interface is necessary. FireWire 400 will usually not suffice for operating more than one Fireface. When using only one Fireface 800, a FireWire 800 interface does not provide any performance advantages, especially does not help to achieve lower latency. But connecting a hard drive to the Fireface (hub functionality), FireWire 800 will immediately increase performance and reliablility [sic]."
Hmm.
Rich
*
If you have the time, patience, interest, etc... I'd be curious to know if
the issue is caused by being in the rack or the hub or both.
It would be cool "hot actually" if you could just put it back in the rack
as is & be fine.
If you do this "experiment" please let us know what you ultimately come to.
Best regards,
ra byn
On Sun, June 5, 2011 1:38 am, Matt wrote:
>
> Well, good news!
>
> I ran a 800-400 cable direct from the Mac Mini to the FireFace80, and
> temporarily deracked the button panel above the FireFace to give it
> breathing space. Result: no console errors and no audible hiccups!
>
> So now I just need to rework the rack to make these new features
> permament. Losing the hubs isn't an issue, as clearly I didn't need
> them anyway. I still need a FW patch; there is a second Mac in the
> rack as a running spare.
Matt
now the rack can stay as is until Tuesday's opening night (not wishing
to touch what ain't broke no more). After that I have time to sit down
and work on it at length.
More next week,
Matt
Matt
Well, three good trouble-free shows; hopefully I've nailed the
problem. Here's what I did:
1. Rewired the rack internally using shorter cabling for USB, FW, MIDI
and ethernet. I'd originally used 2m-3m cables, meaning that an
already compact 4U rack was really packed full. All cables are now
0.75m-1m; long enough to loom up and allow access, but nothing more.
2. Removed the two FW800 hubs. I'd put these in to allow two FW800
ports per Mac Mini (one to patch to the FireFace800, the other to
offer for external drive use), and also to address an assumed FW bus
reset problem (see earlier in this thread). The bus reset problem was
a non-issue with the model of Mac Mini I have, but ironically the
hardware in the FW800 hubs actually recreated the problem! So now each
Mac Mini has a FW800 link to a port on the front panel, where there's
also a third FW800 port which connects back to the FireFace800's 400-
speed FW port. Thus with a short link, either Mac Mini can use the
FireFace. The reduced FW port count means I could also add in four XLR
analogue outs as well as the two existing ADAT outputs, giving a
maximum 20 channels and a more flexible system.
3. Remade the FW patch / remote power button panel using a 1U vent
strip in place of a 1U solid panel. This panel sits directly above the
FireFace and is the only possible area to provide venting (the rack's
rear end is occupied by power distro, signal patch panel, MIDI
interface and a network router). Mounting the buttons and FW sockets
on the vent was a lot easier than I thought, and looks really nice.
Together with the removal of the FW800 hubs and a lot of excess
cabling, there's now a good air path from between and behind the Mac
Minis, up round the back of the FireFace and out through the vent.
4. As an extra airflow trick, I installed a menubar utility called
smcFanControl on both Mac Minis. It displays heatsink temperature and
fan rpm on the menubar, but it also allows you to override the minimum
fan rpm (only upwards, not downwards!). So I set the baseline speed of
the fans to around 2100rpm, which is about 500rpm above the normal.
Still inaudible, but gives some extra flow around the rack.
So far, so good. No audible sound issues and nothing in the Console
log. And the rack runs noticeably cooler. Granted, Scotland is cooler
anyways, but the sun does come out on occasion. :)
I can send images of the rack (and its innards) if anyone's
interested. There are more racks to build, so I've been diligent on
the documentation.
Many thanks to all for the advice and discussions!
Matt