Gonk et al., it is time that I come clean.

I got involved with Outlaw when I was at Cirrus when they were mid-way through the 950 platform in the firmware development at Eastech. I worked closely with Outlaw on such features as Triple-Crossover Bass Management, Cirrus Extra Surround, understanding of the various DSP modes, autodetection, microcontroller interaction, etc.

During my time at Cirrus, I debugged problems like this for a living.

After choosing to advance my career, I left Cirrus to become Director of Product Development for the CHED (Commercial and High-End Division) of Eastech/ATLM Taiwan.

The 970 is based on a platform that I co-designed with the Director of Engineering using an almost all-Cirrus IC solution.

I currently do not work for Eastech any longer as I moved back to Austin, Texas for personal reasons. Living in Taiwan for 2 years and not being able to pick up Mandarin Chinese in itself was quite a challenge. However, if you every have the ability to work overseas, I highly recommend it as it is an invaluable life experience. I am very thankful for the opportunity that was given to me.

Unfortunately, I was not able to see the 1070 or 970 to firmware completion, beta testing then production, but while I was there I did manage the firmware engineer that developed the firmware for both the 970 and 1070, on other projects. He is very smart and very capable.

I was contacted by the Outlaws and asked if I might be able to spend some "free" time to look into this issue.

Iardon, I can sincerely sympathize with your frustration. Believe it or not, I am in the exact same boat. I purchased my 970, and want nothing more than to see this issue brought to closure, because I do agree with you. Regardless of the dollar amount you paid, Outlaw products stand for both quality and value. While this particular bug is not easily repeatable, even for a major Japanese brand (believe me), I can assure you that we will get to the bottom of this.

AVR/Audio Processor designs are amazingly complicated and take even the most proficient company anywhere from 1 ~ 1.5 years to design a platform from the ground up, which this platform was.

Even though I did not write a single line of microcontroller code for this system, from the HIGHLY valuable feedback that the Outlaw Saloon members: pjcrs and iardon have given, I am 100% convinced, what you are experiencing, in terms of the "no audio" issue is definately NOT related to a hardware problem.

This is definately a software problem. Which, as my favorite ex-Outlaw Martha Stewart says, "is a good thing", because it means that this can be fixed (hence the inclusion of the RS-232 port and flash memory capability on this platform).

It appears to be related to the system microcontroller interaction with the DSP autodetection mechanism.

PJSCRS, your descriptions of no-audio combined with "a white noise audio output (scares the hell out of you). This is the same sound you get when you try to play a DTS cd on a non DTS player" are a classic case of telling the DSP that the audio format is AC-3 (or PCM) when in fact it is PCM (or AC-3). What you are hearing is the DSP configured for PCM playback (as this is what the stream looks like to the DSP when you are fast forwarding as the typical stream "clues" are all chopped up, it assumes that what you are sending is PCM. Suddenly, when you start playing again, 20% of the time you are getting the "no audio" problem, which is what the DSP is SUPPOSED to do when it has been configured for PCM, but then detects the incoming stream as AC-3.

This would also account for the 970 "no-audio" output when people are initially turning on their units when a digital audio stream is already being sent to the unit.

When the input source or DSP mode is changed, the microcontroller (should) tell the DSP first look that the incoming stream and THEN upon report of this stream, load the appropriate default or user-preferred DSP mode.

Depending on when the DSP "looks" at the incoming stream, for a brief moment in time (X mS) it may report a compressed stream as a PCM stream, until it sees the correct IEC61937 header identifier and/or compressed stream sync word coming from the S/PDIF input (optical TOSlink or Coaxial), after which it will then report the proper stream to the microcontroller.

Iardon, what is puzzling is the reported "no audio" when the input selection is Analog. Is this highly repeatable? Is there another analog audio source that you might possibly use...i.e. one that is not subject to audio drop-outs of their own (I also own an XM tuner).

The the 970, when the input is analog, this means that the data can not be anything but Linear PCM being sent to the DSP, hence there is no need for the microcontroller to wait for the DSP to report that the incoming stream is PCM, however that does not mean that the DSP should not still be continuously running "autodetect" in the background (which is entirely different than Auto-Poll. It can just set the default, last or user-set DSP mode (which is appropriate for processing Linear PCM) and start processing data.

However, this may well be explained later on as you report "My no audio problems occur only from start up. And it doesn't matter in which order I power up my equipment." To me, this indicates that there is another issue going on where the microcontroller is setting the default DSP mode (or user-preffered DSP mode) without first looking at the audio stream type upon system initialization.

For those that might question the amount of QA that this product went through, I can assure you that thousands of man-hours went into the debugging of the system firmware over the design lifetime of this product just to get it where it is today.

I am at a disadvantage as I do not have access to the labs that I once had where this problem could be diagnosed in a day or two, with an I2C/SPI bus sniffer and scope, provided that the problem was repeatable with the proper source equipment.

If you gents and other members that would like to assist the Outlaws by donating your free time to bring this issue to close (just like me), I am certain that it would be greatly appreciated by the Outlaws.

The data that needs to be collected (in detail) is outline in my previous posting. The more data that is collected (please do not spare ANY detail, including: audio source make and model, digital or analog connection, (if digital) Optical or Coaxial and #, Source input, Source material (e.g. Blade Runner DVD, Dolby Digital 3/2.1 English track, 1 hour, 2 mins, 13 seconds into movie or HDNET channel), Auto-Poll On/Off, DSP mode that the unit is initially in when it is powered up, indicate if the unit starts from analog input and then switches to digital input when Auto-Poll is enabled (or even disabled), methods by which you are able to get the unit to recover from the "no-audio" issue, methods by which you are able to make the "no-audio" issue worse.

The Outlaws are trying their best to get to the bottom of this issue, and we could really use your help.

Thank you in advance.