No audio in HW Compressed MPEG2 container on HVR-1300

No audio in HW Compressed MPEG2 container on HVR-1300

[Shane Harrison]

Hi There,

I am having a problem with getting an audio stream present in the
MPEG2 stream from an HVR-1300 card.

Background
~~~~~~~~~
I am using an HVR-1300 card in a Linux system running 2.6.28.6 vanilla
kernel and using latest v4l2 drivers from the repository.  We are
trying to use the onboard MPEG H/W encoder CX23416 to deliver an
MPEG-2 stream with both audio and video.

To test I capture using "cat /dev/video1 > test.mpg" and I am using
mplayer to play the subsequently captured stream.
Problem
~~~~~~
The delivered MPEG-2 stream generally has no audio component. Mplayer
reports "no audio found".

The same problem exists for both TV input and composite input.  By
repeatedly switching between the TV input and the Composite input we
can eventually get an audio component in the MPEG-2 stream.
Thereafter we always get the audio component until a power off and
restart.  Simply rebooting (no power off) seems to still leave things
in a state where the audio component is in the MPEG-2 stream.

There is a second problem, the audio stream always contains white
noise (I assume TV tuner noise - we don't have it tuned nor an aerial
attached) mixed with the signal applied to the analog in ports.

Analysis
~~~~~~
The most likely scenario is that the hardware is not being initialised
correctly most of the time, once it is initialised correctly then it
works thereafter.  Unfortunately it is difficult to determine the
actual audio path being used.  Clearly the audio comes into the WM8775
(DAC) via a bus switch that switches between the composite/audio on
the back panel and the white header.  It then enters the CX2388x via
the I2S input pins.  We initially assumed that the audio was then
routed through to the CX23416 (MPEG Encoder) via the I2S output pins
of the CX2388x, but we have begun to doubt this assumption since the
CX2388x is set in normal mode by the drivers and the captured audio
doesn't reflect the bit patterns we see on the I2S Data Out line using
an oscilloscope.  That is, when we apply *no* signal to the analog
input, the I2S Dout line is "quiet" yet we hear white noise.

Questions
~~~~~~~~
1) Anyone have any similar experiences?
2) Does anyone have more information on the "blackbird reference
design", in particular can the CX2388x be configured into passthrough
mode so the I2S from the WM8775 goes directly to the CX23416.  I think
the current wiring configuration of the CX23416 to the CX2388x
precludes this?
3) How might the analog signal be being routed to the CX23416 for
encoding if not via the I2S input?


Kind regards
Shane Harrison
Paragon Electronic Design
NZ

Re: No audio in HW Compressed MPEG2 container on HVR-1300

[lawrence rust]

On Mon, 2010-08-02 at 14:15 +1200, Shane Harrison wrote:
> Hi There,
> 
> I am having a problem with getting an audio stream present in the
> MPEG2 stream from an HVR-1300 card.

[snip]

> Problem
> ~~~~~~
> The delivered MPEG-2 stream generally has no audio component. Mplayer
> reports "no audio found".
> 
> The same problem exists for both TV input and composite input.  By
> repeatedly switching between the TV input and the Composite input we
> can eventually get an audio component in the MPEG-2 stream.
> Thereafter we always get the audio component until a power off and
> restart.  Simply rebooting (no power off) seems to still leave things
> in a state where the audio component is in the MPEG-2 stream.
> 
> There is a second problem, the audio stream always contains white
> noise (I assume TV tuner noise - we don't have it tuned nor an aerial
> attached) mixed with the signal applied to the analog in ports.
> 
> Analysis
> ~~~~~~
> The most likely scenario is that the hardware is not being initialised
> correctly most of the time, once it is initialised correctly then it
> works thereafter.  Unfortunately it is difficult to determine the
> actual audio path being used.  Clearly the audio comes into the WM8775
> (DAC) via a bus switch that switches between the composite/audio on
> the back panel and the white header.  It then enters the CX2388x via
> the I2S input pins.  We initially assumed that the audio was then
> routed through to the CX23416 (MPEG Encoder) via the I2S output pins
> of the CX2388x, but we have begun to doubt this assumption since the
> CX2388x is set in normal mode by the drivers and the captured audio
> doesn't reflect the bit patterns we see on the I2S Data Out line using
> an oscilloscope.  That is, when we apply *no* signal to the analog
> input, the I2S Dout line is "quiet" yet we hear white noise.
> 
> Questions
> ~~~~~~~~
> 1) Anyone have any similar experiences?

This sounds very much like the problems that I had with my Nova-S-plus
card while developing a patch to capture line-in audio with composite
video.  Looking at the docs for the wm8775 it appeared that it wasn't
being correctly initialised.  I also found need to change the cx88 code
to mute/un-mute audio in.  Maybe you should try applying this patch, I
posted it to this group on Saturday - see.

http://www.mail-archive.com/linux-media@vger.kernel.org/msg21030.html

-- Lawrence Rust

Fwd: No audio in HW Compressed MPEG2 container on HVR-1300

[Shane Harrison]

On Mon, Aug 2, 2010 at 9:32 PM, lawrence rust <lawrence@softsystem.co.uk> wrote:
>
> On Mon, 2010-08-02 at 14:15 +1200, Shane Harrison wrote:
> > Hi There,
> >
> > I am having a problem with getting an audio stream present in the
> > MPEG2 stream from an HVR-1300 card.
>
> [snip]
>
> > Problem
> > ~~~~~~
> > The delivered MPEG-2 stream generally has no audio component. Mplayer
> > reports "no audio found".
> >
> > The same problem exists for both TV input and composite input.  By
> > repeatedly switching between the TV input and the Composite input we
> > can eventually get an audio component in the MPEG-2 stream.
> > Thereafter we always get the audio component until a power off and
> > restart.  Simply rebooting (no power off) seems to still leave things
> > in a state where the audio component is in the MPEG-2 stream.
> >
> > There is a second problem, the audio stream always contains white
> > noise (I assume TV tuner noise - we don't have it tuned nor an aerial
> > attached) mixed with the signal applied to the analog in ports.
> >
> > Analysis
> > ~~~~~~
> > The most likely scenario is that the hardware is not being initialised
> > correctly most of the time, once it is initialised correctly then it
> > works thereafter.  Unfortunately it is difficult to determine the
> > actual audio path being used.  Clearly the audio comes into the WM8775
> > (DAC) via a bus switch that switches between the composite/audio on
> > the back panel and the white header.  It then enters the CX2388x via
> > the I2S input pins.  We initially assumed that the audio was then
> > routed through to the CX23416 (MPEG Encoder) via the I2S output pins
> > of the CX2388x, but we have begun to doubt this assumption since the
> > CX2388x is set in normal mode by the drivers and the captured audio
> > doesn't reflect the bit patterns we see on the I2S Data Out line using
> > an oscilloscope.  That is, when we apply *no* signal to the analog
> > input, the I2S Dout line is "quiet" yet we hear white noise.
> >
> > Questions
> > ~~~~~~~~
> > 1) Anyone have any similar experiences?
>
> This sounds very much like the problems that I had with my Nova-S-plus
> card while developing a patch to capture line-in audio with composite
> video.  Looking at the docs for the wm8775 it appeared that it wasn't
> being correctly initialised.  I also found need to change the cx88 code
> to mute/un-mute audio in.  Maybe you should try applying this patch, I
> posted it to this group on Saturday - see.
>
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg21030.html
>
> -- Lawrence Rust
>
>
Thanks Lawrence, will give that a whirl tomorrow and the muting idea
might be important in this case as well.  Wierd you posted Saturday
the day after I last worked on this and looked at the archives :-)

I am not ruling out initialisation problems with the WM8775 but I do
always seem to get an I2S output from it that has data in it that
reflects the input.  However it could be the wrong variant of I2S or
some other configuration that isn't set right.  Strange how eventually
I do get audio (albeit mixed with the TV source it appears) simply by
looping thru and changing input sources with v4l2-ctl.

I note that the Nova-S doesn't have the hardware MPEG encoding so
still hoping someone can enlighten me on the audio path when using
that chip.

Cheers
Shane

Re: Fwd: No audio in HW Compressed MPEG2 container on HVR-1300

[lawrence rust]

On Mon, 2010-08-02 at 22:19 +1200, Shane Harrison wrote:
[snip]
> Thanks Lawrence, will give that a whirl tomorrow and the muting idea
> might be important in this case as well.  Wierd you posted Saturday
> the day after I last worked on this and looked at the archives :-)
> 
> I am not ruling out initialisation problems with the WM8775 but I do
> always seem to get an I2S output from it that has data in it that
> reflects the input.  However it could be the wrong variant of I2S or
> some other configuration that isn't set right.

Currently in wm8775.c line 223, R11 is set to 0x21 which is 24-bit left
justified mode.  This is wrong, it should be i2s mode (0x22).  My patch
correctly sets this register and also disables ALC mode which is
irrelevant when setting input level via ALSA and can cause hiss during
quiet sections.

> Strange how eventually
> I do get audio (albeit mixed with the TV source it appears) simply by
> looping thru and changing input sources with v4l2-ctl.

Probably switching glitches eventually hit the right data
synchronisation format.

> I note that the Nova-S doesn't have the hardware MPEG encoding

Correct.

>  so
> still hoping someone can enlighten me on the audio path when using
> that chip.

When a Blackbird cx23416 MPEG encoder is fitted, i2s audio data from the
wm8775 is routed through the cx23883.  The i2s output of the cx23883 is
enabled by the function set_audio_finish() in cx88-tvaudio.c line 148.
The cx23416 can accept stereo Sony I2S format audio data when quoting
from the Conexant datasheet "running its AILR sync signal through an
inverting flip-flop, clocked by an inverted AICKIN".

-- Lawrence Rust

Re: Fwd: No audio in HW Compressed MPEG2 container on HVR-1300

[Shane Harrison]

On Mon, Aug 2, 2010 at 11:59 PM, lawrence rust
<lawrence@softsystem.co.uk> wrote:
> On Mon, 2010-08-02 at 22:19 +1200, Shane Harrison wrote:
> [snip]

>> I am not ruling out initialisation problems with the WM8775 but I do
>> always seem to get an I2S output from it that has data in it that
>> reflects the input.  However it could be the wrong variant of I2S or
>> some other configuration that isn't set right.
>
> Currently in wm8775.c line 223, R11 is set to 0x21 which is 24-bit left
> justified mode.  This is wrong, it should be i2s mode (0x22).  My patch
> correctly sets this register and also disables ALC mode which is
> irrelevant when setting input level via ALSA and can cause hiss during
> quiet sections.
>
>> Strange how eventually
>> I do get audio (albeit mixed with the TV source it appears) simply by
>> looping thru and changing input sources with v4l2-ctl.
>
> Probably switching glitches eventually hit the right data
> synchronisation format.
>
>> I note that the Nova-S doesn't have the hardware MPEG encoding
>
> Correct.
>
>>  so
>> still hoping someone can enlighten me on the audio path when using
>> that chip.
>
> When a Blackbird cx23416 MPEG encoder is fitted, i2s audio data from the
> wm8775 is routed through the cx23883.  The i2s output of the cx23883 is
> enabled by the function set_audio_finish() in cx88-tvaudio.c line 148.
> The cx23416 can accept stereo Sony I2S format audio data when quoting
> from the Conexant datasheet "running its AILR sync signal through an
> inverting flip-flop, clocked by an inverted AICKIN".
>
> -- Lawrence Rust
>
>
>
Yes we had noticed that the WM8775 was in left justified rather than
I2S and had corrected that already.

Thanks for the audio path info.  While you are on a roll, a few more questions ?
1) So do you know how the I2S input (from WM8775) is looped back to
the I2S output that is fed to the MPEG encoder?  I can only assume in
software?  I note that the driver has a comment re. using passthrough
mode in the CX2388x but actually uses normal mode which isn't a
loopback.  Hence something else must generate the I2S output source.
2)  I interpreted the following note in the CX23416 datasheet slightly
differently than you:
       "The CX23416 audio input interface is designed to work with most commonly
       available audio analog-to-digital converters (ADCs) that are
compatible with the Sony
       I2S data format. An I2S-compatible audio part can be supported
by running its AILR
       sync signal through an inverting flip-flop, clocked by an
inverted AICKIN, before
       passing it to the CX23416.
I assumed it was saying it accepted standard Sony variant but you
could connect to Philips I2S if you used a flip-flop to invert and
synchronise with the AICKIN.  I did notice that the HVR1300 board has
a footprint for an IC that is connected to the I2S outputs in some
manner.  I wondered what this was - does something need to be fitted
then to make these two devices talk directly?  I also note that the
driver sets the I2S input to be Philips (as output by the WM8775) and
the I2S output as Sony which seems like an attempt to talk directly.
A bit confused here.....
3) Given I am getting audio sometimes in the MPEG2 stream, is it using
another path into the CX23416.  The idea of getting lucky on switching
glitches seems improbable on the I2S interface since once I get audio
I continue to have it until a hard reboot.  Switching glitches and
race conditions on the control interfaces being successful every so
often I could buy.

Still to try the patch - will let you know.  Unfortunately our
HVR-1300 is in the process of being swapped out since the supplier
wanted to try swapping boards first :-(

Cheers
Shane

Re: Fwd: No audio in HW Compressed MPEG2 container on HVR-1300

[lawrence rust]

On Tue, 2010-08-03 at 09:02 +1200, Shane Harrison wrote:
[snip]
> Thanks for the audio path info.  While you are on a roll, a few more questions ?
> 1) So do you know how the I2S input (from WM8775) is looped back to
> the I2S output that is fed to the MPEG encoder?  I can only assume in
> software?

Yes, it is looped through the cx23883 under s/w control.

>   I note that the driver has a comment re. using passthrough
> mode in the CX2388x but actually uses normal mode which isn't a
> loopback.  Hence something else must generate the I2S output source.

I believe that as long as b13 of AUD_CTL is set then i2s data is output
- this bit is set in set_audio_finish().  The code comment is wrong, as
you say, the i2sctl register is set to normal mode.  In normal mode the
i2s data output is either i2s-in or the demodulated audio from the
analog tuner, dependent upon configuration.

> 2)  I interpreted the following note in the CX23416 datasheet slightly
> differently than you:
>        "The CX23416 audio input interface is designed to work with most commonly
>        available audio analog-to-digital converters (ADCs) that are
> compatible with the Sony
>        I2S data format. An I2S-compatible audio part can be supported
> by running its AILR
>        sync signal through an inverting flip-flop, clocked by an
> inverted AICKIN, before
>        passing it to the CX23416.
> I assumed it was saying it accepted standard Sony variant but you
> could connect to Philips I2S if you used a flip-flop to invert and
> synchronise with the AICKIN.

Yes you are correct, the flip-flop is needed (which is what I wanted to
emphasise) only for _Philips_ mode but the cx23883 i2sout is programmed
for Sony mode in set_audio_finish() i.e. AUD_I2SOUTPUTCNT = 1.

>   I did notice that the HVR1300 board has
> a footprint for an IC that is connected to the I2S outputs in some
> manner.  I wondered what this was - does something need to be fitted
> then to make these two devices talk directly?  I also note that the
> driver sets the I2S input to be Philips (as output by the WM8775) and
> the I2S output as Sony which seems like an attempt to talk directly.
> A bit confused here.....

The wm8775 outputs Philips format in i2s mode and that's what
cx88_set_tvaudio() programs the cx23883 to accept on i2sin.

If the cx23883 were programmed for pass-thru mode then the cx23416 would
receive the wrong data format.  I believe that's the reason for using
'normal' mode.

However, I believe there may be a problem in set_audio_finish() when
CX88_MPEG_BLACKBIRD is set.  If core->tvaudio == WW_I2SADC (which it
true for s-video and composite inputs) then cx88_set_tvaudio() calls
set_audio_finish(core, EN_I2SIN_ENABLE) to enable i2s audio input but in
the CX88_MPEG_BLACKBIRD case the EN_I2SIN_ENABLE is never written to
AUD_CTL.  This may account for the white noise you hear.  You could test
this easily by forcing the cx88 module parameter 'analog' to 1

> 3) Given I am getting audio sometimes in the MPEG2 stream, is it using
> another path into the CX23416.  The idea of getting lucky on switching
> glitches seems improbable on the I2S interface since once I get audio
> I continue to have it until a hard reboot.  Switching glitches and
> race conditions on the control interfaces being successful every so
> often I could buy.
> 
> Still to try the patch - will let you know.  Unfortunately our
> HVR-1300 is in the process of being swapped out since the supplier
> wanted to try swapping boards first :-(

Let us know how you get on.

-- Lawrence Rust

Re: Fwd: No audio in HW Compressed MPEG2 container on HVR-1300

[Shane Harrison]

On Wed, Aug 4, 2010 at 1:48 AM, lawrence rust <lawrence@softsystem.co.uk> wrote:
[snip}
>>
>> Still to try the patch - will let you know.  Unfortunately our
>> HVR-1300 is in the process of being swapped out since the supplier
>> wanted to try swapping boards first :-(
>
> Let us know how you get on.
>
> -- Lawrence Rust

Well still no luck this end.  Have done the following:
1) Swapped boards - no change
2) Applied the patch - no change (we were detecting the WM8775 OK
anyway and the other changes were either non HVR-1300 or we had
already tried them so probably not too surprising
3) Made sure I2SINPUT is enabled - no change

So still have the following strange observations:
1) Repeatedly swapping between inputs eventually gives us audio
2) Once fixed it survives a warm reboot but not power cycle
3) Putting a scope on the I2S line out of the CX2388x shows noise when
TV input selected and no noise for Composite (unless inject a tone).
However MPEG-2 audio always contains hiss or hiss plus injected tone.

So looks like two issues to me.  I'll try and modify the driver so
that when switching inputs we only config the WM8775 or the CX2388x or
the MPEG encoder and see if I can determine which item has the
configuration issue.

Cheers
Shane

Re: Fwd: No audio in HW Compressed MPEG2 container on HVR-1300

[lawrence rust]

On Fri, 2010-08-06 at 11:49 +1200, Shane Harrison wrote:
[snip]
> Well still no luck this end.  Have done the following:
> 1) Swapped boards - no change
> 2) Applied the patch - no change (we were detecting the WM8775 OK
> anyway and the other changes were either non HVR-1300 or we had
> already tried them so probably not too surprising
> 3) Made sure I2SINPUT is enabled - no change
> 
> So still have the following strange observations:
> 1) Repeatedly swapping between inputs eventually gives us audio
> 2) Once fixed it survives a warm reboot but not power cycle

Because of the the warm boot survival I'm tempted to think that this is
a cx23416 firmware problem.

I don't have any experience with cx23416 programming but from looking at
cx88-blackbird.c it appears that the firmware is only loaded from the
function blackbird_initialize_codec() if the chip doesn't respond to a
'ping' command.  blackbird_initialize_codec() is called during probing,
during the first open and whenever the tuner frequency is changed - i.e.
when inputs are changed.  I would be tempted to set this module's debug
parameter and see if there's a coincidence of resetting/reloading the
firmware and the audio path being enabled.

> 3) Putting a scope on the I2S line out of the CX2388x shows noise when
> TV input selected and no noise for Composite (unless inject a tone).

This confirms that the cx2388x is setup OK

> However MPEG-2 audio always contains hiss or hiss plus injected tone.

This tells me that the cx23416 is not configured right.

> So looks like two issues to me.  I'll try and modify the driver so
> that when switching inputs we only config the WM8775 or the CX2388x or
> the MPEG encoder and see if I can determine which item has the
> configuration issue.

Seems like a good idea, but I would put money on the cx23416.

I would recommend looking at the debug output from cx88-blackbird and if
there's anything unusual then temporarily disable the ping test in
blackbird_initialize_codec() and always reset and re-load the firmware.
If this helps then maybe add some delays around the reset for a long
term fix.

-- Lawrence Rust

Re: Fwd: No audio in HW Compressed MPEG2 container on HVR-1300

[Andy Walls]

On Fri, 2010-08-06 at 11:40 +0200, lawrence rust wrote:
> On Fri, 2010-08-06 at 11:49 +1200, Shane Harrison wrote:
> [snip]
> > Well still no luck this end.  Have done the following:
> > 1) Swapped boards - no change
> > 2) Applied the patch - no change (we were detecting the WM8775 OK
> > anyway and the other changes were either non HVR-1300 or we had
> > already tried them so probably not too surprising
> > 3) Made sure I2SINPUT is enabled - no change
> > 
> > So still have the following strange observations:
> > 1) Repeatedly swapping between inputs eventually gives us audio
> > 2) Once fixed it survives a warm reboot but not power cycle
> 
> Because of the the warm boot survival I'm tempted to think that this is
> a cx23416 firmware problem.

I recommend you check the ivtv-devel list archives from earlier this
year.  A few fixes were put in place to deal with the CX23416 startup
and flickering video, and CX23416 audio not working.

I can only find this reference right now:

http://www.gossamer-threads.com/lists/ivtv/devel/40907#40907

You can check the latest changes to the ivtv driver for some help in
what actions may help the situation.  (Keep in mind many ivtv designs
are being fed from the I2S output of a CX25843 though.)


> I don't have any experience with cx23416 programming but from looking at
> cx88-blackbird.c it appears that the firmware is only loaded from the
> function blackbird_initialize_codec() if the chip doesn't respond to a
> 'ping' command.  blackbird_initialize_codec() is called during probing,
> during the first open and whenever the tuner frequency is changed - i.e.
> when inputs are changed.  I would be tempted to set this module's debug
> parameter and see if there's a coincidence of resetting/reloading the
> firmware and the audio path being enabled.
> 
> > 3) Putting a scope on the I2S line out of the CX2388x shows noise when
> > TV input selected and no noise for Composite (unless inject a tone).
> 
> This confirms that the cx2388x is setup OK
> 
> > However MPEG-2 audio always contains hiss or hiss plus injected tone.
> 
> This tells me that the cx23416 is not configured right.

Well maybe.  Looking at Martin's and Ian's troubleshooting on the
ivtv-devel list from earlier this year, there appear to be some races
within the firmware itself and some sensitivities to when clock lines
are active when reconfiguring.


> 
> > So looks like two issues to me.  I'll try and modify the driver so
> > that when switching inputs we only config the WM8775 or the CX2388x or
> > the MPEG encoder and see if I can determine which item has the
> > configuration issue.
> 
> Seems like a good idea, but I would put money on the cx23416.

I wouldn't bet against you on that one.


> I would recommend looking at the debug output from cx88-blackbird and if
> there's anything unusual then temporarily disable the ping test in
> blackbird_initialize_codec() and always reset and re-load the firmware.

The ping command itself should be harmless.


> If this helps then maybe add some delays around the reset for a long
> term fix.

Delays here and there and gating clocks off and then back on are about
all that you have at your disposal.

I don't know if the cx88 driver supports it, but the ivtv driver
provides a /dev/video24 that provides the raw PCM stream from the
CX23416.  If the cx88 driver supports that, it may be another test point
worth checking: aplay -f dat < /dev/video24 .


Regards,
Andy

> -- Lawrence Rust

Re: Fwd: No audio in HW Compressed MPEG2 container on HVR-1300

[Andy Walls]

On Fri, 2010-08-06 at 11:40 +0200, lawrence rust wrote:
> On Fri, 2010-08-06 at 11:49 +1200, Shane Harrison wrote:

> > Well still no luck this end.  Have done the following:

> > 2) Applied the patch - no change (we were detecting the WM8775 OK

BTW, I forgot to mention the ivtv driver uses the WM8775 module for the
PVR-150 card.  Changes to that module that affect the default setting
needs to be done in a way that doesn't break the PVR-150.

Maybe a .s_config() method in the WM8775 v4l2_subdev_core_ops would be
the way to do that, or by passing parameters in struct i2c_board_info
(according to a recent post by Hans Verkuil).

Regards,
Andy

Re: Fwd: No audio in HW Compressed MPEG2 container on HVR-1300

[lawrence rust]

On Fri, 2010-08-06 at 08:22 -0400, Andy Walls wrote:
> On Fri, 2010-08-06 at 11:40 +0200, lawrence rust wrote:
> > On Fri, 2010-08-06 at 11:49 +1200, Shane Harrison wrote:
> 
> > > Well still no luck this end.  Have done the following:
> 
> > > 2) Applied the patch - no change (we were detecting the WM8775 OK
> 
> BTW, I forgot to mention the ivtv driver uses the WM8775 module for the
> PVR-150 card.  Changes to that module that affect the default setting
> needs to be done in a way that doesn't break the PVR-150.
> 

I believe that the patch that I posted for wm8775.c preserves the
original functionality (for ivtv and other dependants) although it
clearly achieves this through a different sequence of register writes.
The only major change to function is from ALC to manual level control
using the ALSA mixer API - which generally gives a better audio
experience.

> Maybe a .s_config() method in the WM8775 v4l2_subdev_core_ops would be
> the way to do that, or by passing parameters in struct i2c_board_info
> (according to a recent post by Hans Verkuil).

Good idea. If my current method breaks any existing code then I'll do
that, but for the moment I believe that they can co-exist.

Comments, criticisms and errata much appreciated.

> 
> Regards,
> Andy

-- Lawrence