Mailing List Archive

My experience with MythTV annoyances, 0.20.1 version
Now that an official 0.20.1 release is out, it's time to reexamine the
list of minor remaining annoyances I previously discussed in June
(<URL:http://www.gossamer-threads.com/lists/mythtv/users/208552#208552>)
and October
(<URL:http://www.gossamer-threads.com/lists/mythtv/users/233570#233570>)
2006.

Since October 2006, my setup has changed in the following ways:

* Old: 2TB of MythTV-dedicated storage on an EXT3-based RAID 0
NAS. New: Several times more storage on two JFS RAID 5/6 arrays.
* New: A new quad-core slave backend/RAID 6 array (see above) has
joined the existing frontend/master backend.
* Old: Analog output to a 2.1 speaker system. New: SP/DIF output to a
new 5.1 speaker system and receiver.
* Old: 32-bit Fedora Core 4 on the frontend/backend. New: 64-bit
Fedora Core 6
(<URL:http://www.gossamer-threads.com/lists/mythtv/users/238963#238963>.

Current remaining annoyances:

* The move to 5.1 digital audio revealed a problem with the audio in
about half of the recordings I make from analog (sub-100) cable
channels
(<URL:http://www.gossamer-threads.com/lists/mythtv/users/241814#241814>).
Before Mike Dean jumps in, let me stress again that this has nothing
to do with ALSA configuration files (and if he or anyone else can
prove me wrong, I'd very much welcome it) or lack thereof.
* Some remaining occasional stability issues that result in
mythbackend dying (perhaps once every two or three weeks) with the
chalk marks of the corpse visible in dmesg. While much, much, much
improved from 0.19 or the early days of 0.20, the occasional death
still occurs. I strongly suspect that there are a few remaining
obscure bugs in mythbackend, ffmpeg (see
<URL:http://www.gossamer-threads.com/lists/mythtv/users/263934#263934>),
and/or libmpeg2 serious enough to kill mythbackend when generating
preview bitmaps. As Mike Dean notes
(<URL:http://www.gossamer-threads.com/lists/mythtv/users/269323#269323>,
there's actually no way to stop the bitmaps from being
created. Perhaps
0.20.1 marks the final elimination of such bugs killing mythbackend,
but I'd rather not find out the hard way and would prefer to be able
to shut down preview-bitmap generation entirely.

Another semi-reliable source of mythbackend deaths back in the day
was pulling up the MythTV HTML status page, either through MythWeb
or (especially) http://mythtv:6544/. These crashes have also very,
very drastically diminished in intensity but I'm not quite ready to
declare them as extinct as smallpox yet.
* The mystery write-hang issue I detail at
<URL:http://www.gossamer-threads.com/lists/mythtv/users/242065#242065>.
As far as I can tell, I have solved the issue--which is not related
to MythTV, but has something to do with frequent/lengthy writes to
the boot partition--by moving /var/lib/mysql (and /var/log/mythtv,
although this was almost-certainly unnecessary) to another disk (I
had it on one of the MythTV-dedicated RAID arrays for a while) or to
another partition on the boot drive (as I currently do so); see
<URL:http://www.gossamer-threads.com/lists/mythtv/users/267763#267763>.
* I still very occasionally (once a week, perhaps) see mythfrontend
dying, typically when I jump to Recorded Programs or do something
else from within one of the setup screens. Since when mythfrontend
dies on my frontend the mythtv user automatically logs itself out
and back in, restarting mythfrotend along the way, it's never been a
big deal.

. . . And that's it. Really. 99 and 44/100ths of the time my MythTV
setup is rock solid and easy to install and fiddle with.

I'll bet I'm not alone in having put off trying MythTV out because of
all the horror stories about just how hard it was to get up and
running. I've never found it so all the way back to my first day back
in December 2005 when I sat back and pulled up a high-definition
recording I captured via FireWire. I remain convinced that 95% of the
problems people ask about here are because they do not take sufficient
advantage of the mountain of resources available to answer their
questions. As always, my thanks to the entire MythTV community for a
truly world-class project.

--
Yeechang Lee <ylee@pobox.com> | +1 650 776 7763 | San Francisco CA US
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: My experience with MythTV annoyances, 0.20.1 version [ In reply to ]
On 05/14/2007 12:47 AM, Yeechang Lee wrote:
> * Some remaining occasional stability issues that result in
> mythbackend dying (perhaps once every two or three weeks) with the
> chalk marks of the corpse visible in dmesg. While much, much, much
> improved from 0.19 or the early days of 0.20, the occasional death
> still occurs. I strongly suspect that there are a few remaining
> obscure bugs in mythbackend, ffmpeg (see
> <URL:http://www.gossamer-threads.com/lists/mythtv/users/263934#263934>),
> and/or libmpeg2 serious enough to kill mythbackend when generating
> preview bitmaps. As Mike Dean notes
> (<URL:http://www.gossamer-threads.com/lists/mythtv/users/269323#269323>,
> there's actually no way to stop the bitmaps from being
> created. Perhaps
> 0.20.1 marks the final elimination of such bugs killing mythbackend,
> but I'd rather not find out the hard way and would prefer to be able
> to shut down preview-bitmap generation entirely.

http://svn.mythtv.org/trac/ticket/3361

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: My experience with MythTV annoyances, 0.20.1 version [ In reply to ]
Michael T. Dean <mtdean@thirdcontact.com> says:
> http://svn.mythtv.org/trac/ticket/3361

Glad to see it! Further progress in the asymptotic move toward a 100%
(as opposed to 99.44%)-stable MythTV!

--
Yeechang Lee <ylee@pobox.com> | +1 650 776 7763 | San Francisco CA US
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: My experience with MythTV annoyances, 0.20.1 version [ In reply to ]
On 05/14/2007 12:47 AM, Yeechang Lee wrote:
> * Old: Analog output to a 2.1 speaker system. New: SP/DIF output to a
> new 5.1 speaker system and receiver.
...
> * The move to 5.1 digital audio revealed a problem with the audio in
> about half of the recordings I make from analog (sub-100) cable
> channels
> (<URL:http://www.gossamer-threads.com/lists/mythtv/users/241814#241814>).
> Before Mike Dean jumps in, let me stress again that this has nothing
> to do with ALSA configuration files (and if he or anyone else can
> prove me wrong, I'd very much welcome it) or lack thereof.

You have a broken ALSA configuration (among other things) preventing
proper playback. :)

<pet-peeve>How can someone say their configuration is not broken when
they are unable to get something to work? In that situation, the only
way I can see to know for sure that the configuration is not broken is
to try every single possible configuration. Since that's completely
impossible, what benefit does saying, "It doesn't work, but I /know/ my
configuration is correct," provide? Lack of evidence does not
constitute evidence.</pet-peeve>

I'm assuming you're trying to use AC-3 passthrough (and, as you
mentioned in the other thread, you have some 32kHz AC-3). I'm also
assuming you've properly configured your sound card for IEC958 output
(available through ALSA's built-in PCM names iec958 and spdif). I'm
further assuming (and this is probably going too far in my assumptions)
that your sound card supports a "discrete" IEC958 input (many (most?)
don't) /and/ supports 32kHz AC-3 passthrough (and many don't--they'll
always slurp in data at 48kHz causing Myth to try to catch up on video
playback). If all these assumptions are correct, then everything should
just work--if you have a receiver that properly autodetects rate/format
and adjusts the IEC958 status appropriately (this one, however, /is/ a
pretty good assumption--I don't think consumers would have accepted
digital audio if they needed to know how everything works; rather they
want it to just work and receivers were designed to handle "broken"
audio input so this would be the case).

If these assumptions are /all/ correct, you can set your audio
passthrough device to
"ALSA:iec958:AES0=0x06,AES1=0x82,AES2=0x00,AES3=0x03" (or
"ALSA:spdif:AES0=0x06,AES1=0x82,AES2=0x00,AES3=0x03") and Myth should
play a 32kHz AC-3 stream without issue (whether your receiver can is a
whole other question, though). Of course, this will completely break
playback of 48kHz AC-3 streams (but you could just go into setup and
replace the AES3 stanza with "AES3=0x02" for 48kHz or "AES3=0x00" for
44.1kHz). If you try this, I can almost guarantee, though that it won't
work. Why, because your sound card probably doesn't support AC-3 at any
rate other than 48kHz...

If your sound card does not support a discrete IEC958 input (i.e. the
sound processing chip pulls samples from another input--such as one of
the PCM inputs--like most (all?) of the nForce/Via/Realtek-based cards)
you'll either need a bunch of extra plumbing for something like this to
work--if you're lucky--or a new sound card that actually supports 32kHz
passthrough (as "passthrough" is a bit of a loose definition when the
data is pulled from anything other than a discrete IEC958 input).

I don't know of any specific sound cards that pull data from non-IEC958
inputs but respect the IEC958 rate set on the IEC958 input--all I've
ever heard of assume an AC-3 rate that matches the PCM input's rate (and
since the same boards that leave off traces to the discrete IEC958 input
tend to use fixed-48kHz PCM input with software (driver) rate
conversion, they don't support AC-3 at any rate other than 48kHz). The
IEC958 rate setting is then just as useless as the sound processing
chip's not-connected-to-anything IEC958 input. After all, generally,
the manufacturer-supplied drivers (on Windows) will completely hide the
disconnected discrete input, so why would the card respect its settings.

But, wait! It works in Windows! Well, the Windows drivers are probably
decoding and re-encoding the AC-3 stream on the fly (although some
drivers use "hardware" decoders/encoders on the card, if present, but
still they're re-encoding)...

As a matter of fact, it's probably Windows and Microsoft and Intel you
have to thank for your broken sound card. Even though the IEC958
specification explicitly allows 32kHz, 44.1kHz, and 48kHz rates, the
AC'97 specifications required that audio hardware support 96kHz 20-bit
stereo and 48kHz 20-bit stereo or 48kHz multichannel recording and
playback to be compliant. The successor to AC'97 (Intel High Definition
Audio (HD Audio/IHD)), released in 2004, allows 192kHz 32-bit stereo or
96kHz 32-bit 8-channel audio. TTBOMK (and I'll admit my Windows
knowledge is minimal), Windows XP didn't provide support for IHD, so
until Vista was released vendors had little reason to support it,
either, so most sound cards out there today are still AC'97 cards
(although some have started to appear with IHD support). But my
Creative SoundBlaster Live! (or later) allows me to pass in audio at any
rate without using the plug plugin to do rate conversion, so wouldn't
that violate AC'97? No. AC'97 simply specifies a means of linking a
CODEC chip (has nothing to do with binary formats, like MP3) to a
digital controller chip using 5 wires. Vendors can do anything they
want before or after those connections, like include a DSP that
resamples to 48kHZ (as in the Live!/Audigy/Extigy series) or use
software resampling in drivers. The point is that because AC'97
requires a 48kHz digital link, resampling was required for any other
rate, and since most vendors were unwilling to add additional hardware,
they used driver-based resampling. Since they could do all that without
enabling the dedicated IEC958 input, there was little reason to do so:
once the architecture was in place for rate conversion of PCM, extending
it to decode/re-encode AC-3 was easier (and likely cheaper).

But, wait! It works in MPlayer/xine! Well, MPlayer and xine are
"smarter" than users (they've taken the approach that most users don't
know--or even care to know--what's happening; they just want to watch
their video with sound). If the user specifies passthrough, but the
media player is told by the sound card that it requires a 48kHz audio
stream, it will decode the AC-3--regardless of your passthrough
settings. So, how come I get multi-channel audio? Well, it could be
your receiver or it could be your sound card configuration causing you
to think you have multi-channel audio when in fact it's plain old stereo
(replicated to multiple channels). There are so many possibilities that
I can't tell you unless I can see your entire configuration. (And,
really, I have my own configuration to worry about.) In other words, if
you ever find an app you can use to output a 32kHz AC-3 stream from your
sound card such that your receiver shows 32kHz AC-3 on its little LCD,
then talk to me and we can get into the details.

So, if your sound card (and/or driver) does not support 32kHz AC-3
passthrough, the /only/ thing MythTV could do to allow AC-3 passthrough
to work for a recording with a 32kHz AC-3 stream is to decode it and
re-encode it to a 48kHz AC-3 stream (complete with generational loss).
Now, this may eventually be possible as a side-effect (or just another
part of) #1104, but it's not currently possible.

One of these days, I may write the code to allow MythTV to automatically
choose the right IEC958 status bits and send them to the receiver. This
would allow users whose sound cards support 32kHz or 44.1kHz AC-3 and a
discrete IEC958 input to properly specify the audio type/rate, but it
won't do anything for those whose sound cards support only 48kHz AC-3
(for that, you'll have to talk to someone else, like Dr. Mark Spieth of
#1104, who might be interested in adding AC-3 re-encoding support).
However, I will admit that I have a few higher priority things to do
first--such as build and set up my 5.1 (or 7.1) channel speaker system.
(In other words, it might take a bit as it's pretty low priority for
me--especially now since I don't have a surround speaker system.)
However, once I write the code it will do properly what #1105 (
http://svn.mythtv.org/trac/ticket/1105 ) and #1598 (
http://svn.mythtv.org/trac/ticket/1598 ) and #1608 (
http://svn.mythtv.org/trac/ticket/1608 ) tried to do. In the meantime,
those with auto-detecting receivers (and extremely nice sound cards)
should have it easy (and, like I said, most receivers auto-detect just
fine--the patch would just minimize the pops/clicks as the receiver
switches modes). Then again, I may find a way to get an HDMI 1.3+ audio
connection so I can send 8 channels of 192kHz 24-bit uncompressed PCM
audio via a digital link (and avoid the whole AC-3 generational loss).
(Note, this probably helps you to infer the kind of timeline I'm talking
about for writing this code.)

Of course, if you're one of the lucky ones who has a sound card on which
the manufacturer decided to connect the discrete IEC958 input (and that
supports 32kHz passthrough), there's no reason any useful program should
ever force a user to use a cryptic configuration string like
"ALSA:iec958:AES0=0x06,AES1=0x82,AES2=0x00,AES3=0x03". Instead,
wouldn't it be nice to be able to put that information somewhere where
it could be reused in any application using a nice, simple-to-remember
human-readable-and-understandable name? /That/ is the entire reason for
an ALSA configuration file. Therefore, it makes no sense to say, "You
don't need an ALSA configuration file." Really, I don't need Myth,
either. I could just type a bunch of cryptic commands at the console
that create cron/at jobs to execute the commands required to set up
capture cards and record programs (I'm guessing it would take about 42
lines of Perl code ;). Myth--like an ALSA configuration file--is meant
to make the user experience a little bit more enjoyable.

So you could, instead, put the above configuration information into an
ALSA configuration file. Something like the bit at the bottom of this
post would allow you to specify "ALSA:passthru32k" for a 32-kHZ AC-3
passthrough device. Note, however, that I doubt this will "fix" issues
with 32kHz passthrough for very many people since most are probably
having issues due to lack of support from the card.

Show me a sound configuration problem and I'll show you a sound
configuration problem that can be fixed with ALSA configuration
files... Unfortunately, people hate what they don't understand, so they
love to say, "It's not an ALSA configuration file problem," or "This
[ALSA configuration file] is not required on Fedora Core 5 and 6
systems," or "If you are using a version of ALSA newer than 1.0.12 --
<supposedly authoritative source> states that for most uses an .asoundrc
is not necessary."

I've given up on trying to fix the completely broken Wiki page on
Configuring Digital Sound (
http://www.mythtv.org/wiki/index.php/Configuring_Digital_Sound ) because
people think that just because something worked for them, they can make
an authoritative statement about proper configuration. I also wholly
agree with Bruce Markey's dislike of people's posting his words to the
wiki as the Configuring Digital Sound page was created by copy/pasting
my words from one of my posts directed at a specific set of users having
a specific issue with 5.1-channel analog audio on the NFORCE2 and
explaining why it wasn't working by explaining what they were doing
incorrectly with the ALSA configuration files. When the info was
copied, the words were attributed to me--which was perfectly reasonable
at the time because I actually said them. Then, a lot of people started
changing the page--including words attributed to me--without changing
the attribution. Since I never really looked at the wiki for the first
6 months, I was "credited" with a /lot/ of inaccurate information until
I finally took my name out of the page (and fixed some of the
inaccuracies and removed the "how to understand and write an ALSA
configuration" part (leaving a link to my post) since no one read
it--instead just copying the example and proclaiming it either works or
doesn't). But, I haven't really touched the page since then, and doing
so isn't worth my time as anything I correct would tend to be
uncorrected again--if not where I corrected it, in some other comment
somewhere else on the page or on some other page (i.e. someone makes a
new page to say what they want because their "opinion" differs from the
existing page).

So, basically, I've been ignoring the discussion of sound configuration
for quite some time because it's a very complex issue when you realize
the vast number of sound cards out there and, although they use a
limited number of chips--after all, there aren't that many ALSA
drivers--those chips are hooked up in /very/ different ways, requiring
very different configurations, especially when you factor in the various
permutations of sound card/receiver combos (which can also have a big
effect on perceived usability). And, you may have noticed, I can get a
bit spun-up over it, too. Unfortunately, it seems most don't care to
learn how things work or even how their equipment works (so they can
figure out their own proper configuration) but instead want a
configuration they can read off a wiki page. And, what's worse, once
they figure out something that works for their system and audio files,
they spread it around as "universally" authoritative configuration help.

The only reason I responded to this e-mail was your insistence that it's
not an ALSA configuration issue and your mentioning me as the guy who
always says that sound can be fixed with the ALSA configuration files.
I'll admit that you were pretty much right on the second--I always say
ALSA configuration issues can be fixed with ALSA configuration
files--and I stand by my opinion (and would actually go so far as to say
ALSA configuration issues /should/ be fixed with ALSA configuration
files). Wow. You're still reading this? It just so happens that most
sound issues (and many playback issues) are caused by broken ALSA
configurations. Some, however, may be caused by users trying to get
their hardware to do things it can't do (like play 32kHz AC-3 audio via
passthrough)--or, put another (less accusatory) way, because of
broken/incapable sound cards.

The reason I took forever to respond to the e-mail is because, well, it
took forever to find enough free time to write it (just like--I'm sure
you're thinking--it took forever to read it). And, it was very low
priority because I had been assured that your issue had nothing to do
with ALSA configuration ;), and besides, I've been accused of being an
ALSA-configuration-file zealot and don't want to feed the rumors.

Mike "extra-wordy ALSA-configuration-file zealot" Dean

Example ALSA conf fragment for a sound card that pulls IEC958 data from
a PCM input where the "digital-hw" device is set up to properly output
PCM via the digital output.

This fragment relies on the rest of the ALSA configuration file at
http://www.mythtv.org/wiki/index.php/Configuring_Digital_Sound#Setting_up_ALSA.27s_.asoundrc.2C_Properly
and should be appended to the end of the config file. The only devices
that should be used by the user are "passthru32k", "passthru44k", and
"passthru48k". Using this fragment, the user does not even have to
worry about setting the IEC958 settings on the card. Note that the
passthru32k and passthru44k are likely to work the same as passthru48k
(i.e. the sound card most likely only allows 48kHz AC-3 passthrough and
will ignore the rate specified in the IEC958 status bits, so the user
should specify "ALSA:passthru48k" as Myth's "Passthrough output device"
just so the name is more "correct" as to the sound card's
capabilities). This fragment will /only/ work with sound cards without
a discrete IEC958 input that pull IEC958 input from a PCM input (which
likely only support 48kHz passthrough)!

# Use the ALSA device name "passthru32k" for 32kHz encoded audio (i.e. AC-3,
# DTS, ...) passthrough.
pcm.passthru32k {
type plug
slave.pcm "passthru:AES0=0x06,AES1=0x82,AES2=0x00,AES3=0x03"
}

# Control device (mixer, etc.) for the card
ctl.passthru32k {
type hw
card 0
}

# Use the ALSA device name "passthru44k" for 44.1kHz encoded audio (i.e.
AC-3,
# DTS, ...) passthrough.
pcm.passthru44k {
type plug
slave.pcm "passthru:AES0=0x06,AES1=0x82,AES2=0x00,AES3=0x00"
}

# Control device (mixer, etc.) for the card
ctl.passthru44k {
type hw
card 0
}

# Use the ALSA device name "passthru48k" for 48kHz encoded audio (i.e. AC-3,
# DTS, ...) passthrough.
pcm.passthru48k {
type plug
slave.pcm "passthru:AES0=0x06,AES1=0x82,AES2=0x00,AES3=0x02"
}

# Control device (mixer, etc.) for the card
ctl.passthru48k {
type hw
card 0
}

# Generic passthrough device which accepts IEC958 status bits and sets
IEC958
# controls for proper passthrough on a card without a discrete IEC958 input
# connection that instead pulls non-audio data from PCM
pcm.passthru {
@args [ AES0 AES1 AES2 AES3 ]
@args.AES0 {
type integer
}
@args.AES1 {
type integer
}
@args.AES2 {
type integer
}
@args.AES3 {
type integer
}
type hooks
slave.pcm "digital-hw"
hooks.0 {
type ctl_elems
hook_args [.
{
name "IEC958 Playback Switch"
lock true
preserve true
value true
}
{
name "IEC958 Playback AC97-SPSA"
lock true
preserve true
value 0
}
{
name "IEC958 Playback Source"
lock true
preserve true
value 0
}
{
name "IEC958 Playback Default"
lock true
preserve true
value [ $AES0 $AES1 $AES2 $AES3 ]
}
]
}
}

# Control device (mixer, etc.) for the card
ctl.passthru {
type hw
card 0
}


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: My experience with MythTV annoyances, 0.20.1 version [ In reply to ]
Boy Mike. You seriously have too much time on your hands! ;-)

- Mark

On 6/21/07, Michael T. Dean <mtdean@thirdcontact.com> wrote:
> On 05/14/2007 12:47 AM, Yeechang Lee wrote:
> > * Old: Analog output to a 2.1 speaker system. New: SP/DIF output to a
> > new 5.1 speaker system and receiver.
> ...
> > * The move to 5.1 digital audio revealed a problem with the audio in
> > about half of the recordings I make from analog (sub-100) cable
> > channels
> > (<URL:http://www.gossamer-threads.com/lists/mythtv/users/241814#241814>).
> > Before Mike Dean jumps in, let me stress again that this has nothing
> > to do with ALSA configuration files (and if he or anyone else can
> > prove me wrong, I'd very much welcome it) or lack thereof.
>
> You have a broken ALSA configuration (among other things) preventing
> proper playback. :)
>
> <pet-peeve>How can someone say their configuration is not broken when
> they are unable to get something to work? In that situation, the only
> way I can see to know for sure that the configuration is not broken is
> to try every single possible configuration. Since that's completely
> impossible, what benefit does saying, "It doesn't work, but I /know/ my
> configuration is correct," provide? Lack of evidence does not
> constitute evidence.</pet-peeve>
>
> I'm assuming you're trying to use AC-3 passthrough (and, as you
> mentioned in the other thread, you have some 32kHz AC-3). I'm also
> assuming you've properly configured your sound card for IEC958 output
> (available through ALSA's built-in PCM names iec958 and spdif). I'm
> further assuming (and this is probably going too far in my assumptions)
> that your sound card supports a "discrete" IEC958 input (many (most?)
> don't) /and/ supports 32kHz AC-3 passthrough (and many don't--they'll
> always slurp in data at 48kHz causing Myth to try to catch up on video
> playback). If all these assumptions are correct, then everything should
> just work--if you have a receiver that properly autodetects rate/format
> and adjusts the IEC958 status appropriately (this one, however, /is/ a
> pretty good assumption--I don't think consumers would have accepted
> digital audio if they needed to know how everything works; rather they
> want it to just work and receivers were designed to handle "broken"
> audio input so this would be the case).
>
> If these assumptions are /all/ correct, you can set your audio
> passthrough device to
> "ALSA:iec958:AES0=0x06,AES1=0x82,AES2=0x00,AES3=0x03" (or
> "ALSA:spdif:AES0=0x06,AES1=0x82,AES2=0x00,AES3=0x03") and Myth should
> play a 32kHz AC-3 stream without issue (whether your receiver can is a
> whole other question, though). Of course, this will completely break
> playback of 48kHz AC-3 streams (but you could just go into setup and
> replace the AES3 stanza with "AES3=0x02" for 48kHz or "AES3=0x00" for
> 44.1kHz). If you try this, I can almost guarantee, though that it won't
> work. Why, because your sound card probably doesn't support AC-3 at any
> rate other than 48kHz...
>
> If your sound card does not support a discrete IEC958 input (i.e. the
> sound processing chip pulls samples from another input--such as one of
> the PCM inputs--like most (all?) of the nForce/Via/Realtek-based cards)
> you'll either need a bunch of extra plumbing for something like this to
> work--if you're lucky--or a new sound card that actually supports 32kHz
> passthrough (as "passthrough" is a bit of a loose definition when the
> data is pulled from anything other than a discrete IEC958 input).
>
> I don't know of any specific sound cards that pull data from non-IEC958
> inputs but respect the IEC958 rate set on the IEC958 input--all I've
> ever heard of assume an AC-3 rate that matches the PCM input's rate (and
> since the same boards that leave off traces to the discrete IEC958 input
> tend to use fixed-48kHz PCM input with software (driver) rate
> conversion, they don't support AC-3 at any rate other than 48kHz). The
> IEC958 rate setting is then just as useless as the sound processing
> chip's not-connected-to-anything IEC958 input. After all, generally,
> the manufacturer-supplied drivers (on Windows) will completely hide the
> disconnected discrete input, so why would the card respect its settings.
>
> But, wait! It works in Windows! Well, the Windows drivers are probably
> decoding and re-encoding the AC-3 stream on the fly (although some
> drivers use "hardware" decoders/encoders on the card, if present, but
> still they're re-encoding)...
>
> As a matter of fact, it's probably Windows and Microsoft and Intel you
> have to thank for your broken sound card. Even though the IEC958
> specification explicitly allows 32kHz, 44.1kHz, and 48kHz rates, the
> AC'97 specifications required that audio hardware support 96kHz 20-bit
> stereo and 48kHz 20-bit stereo or 48kHz multichannel recording and
> playback to be compliant. The successor to AC'97 (Intel High Definition
> Audio (HD Audio/IHD)), released in 2004, allows 192kHz 32-bit stereo or
> 96kHz 32-bit 8-channel audio. TTBOMK (and I'll admit my Windows
> knowledge is minimal), Windows XP didn't provide support for IHD, so
> until Vista was released vendors had little reason to support it,
> either, so most sound cards out there today are still AC'97 cards
> (although some have started to appear with IHD support). But my
> Creative SoundBlaster Live! (or later) allows me to pass in audio at any
> rate without using the plug plugin to do rate conversion, so wouldn't
> that violate AC'97? No. AC'97 simply specifies a means of linking a
> CODEC chip (has nothing to do with binary formats, like MP3) to a
> digital controller chip using 5 wires. Vendors can do anything they
> want before or after those connections, like include a DSP that
> resamples to 48kHZ (as in the Live!/Audigy/Extigy series) or use
> software resampling in drivers. The point is that because AC'97
> requires a 48kHz digital link, resampling was required for any other
> rate, and since most vendors were unwilling to add additional hardware,
> they used driver-based resampling. Since they could do all that without
> enabling the dedicated IEC958 input, there was little reason to do so:
> once the architecture was in place for rate conversion of PCM, extending
> it to decode/re-encode AC-3 was easier (and likely cheaper).
>
> But, wait! It works in MPlayer/xine! Well, MPlayer and xine are
> "smarter" than users (they've taken the approach that most users don't
> know--or even care to know--what's happening; they just want to watch
> their video with sound). If the user specifies passthrough, but the
> media player is told by the sound card that it requires a 48kHz audio
> stream, it will decode the AC-3--regardless of your passthrough
> settings. So, how come I get multi-channel audio? Well, it could be
> your receiver or it could be your sound card configuration causing you
> to think you have multi-channel audio when in fact it's plain old stereo
> (replicated to multiple channels). There are so many possibilities that
> I can't tell you unless I can see your entire configuration. (And,
> really, I have my own configuration to worry about.) In other words, if
> you ever find an app you can use to output a 32kHz AC-3 stream from your
> sound card such that your receiver shows 32kHz AC-3 on its little LCD,
> then talk to me and we can get into the details.
>
> So, if your sound card (and/or driver) does not support 32kHz AC-3
> passthrough, the /only/ thing MythTV could do to allow AC-3 passthrough
> to work for a recording with a 32kHz AC-3 stream is to decode it and
> re-encode it to a 48kHz AC-3 stream (complete with generational loss).
> Now, this may eventually be possible as a side-effect (or just another
> part of) #1104, but it's not currently possible.
>
> One of these days, I may write the code to allow MythTV to automatically
> choose the right IEC958 status bits and send them to the receiver. This
> would allow users whose sound cards support 32kHz or 44.1kHz AC-3 and a
> discrete IEC958 input to properly specify the audio type/rate, but it
> won't do anything for those whose sound cards support only 48kHz AC-3
> (for that, you'll have to talk to someone else, like Dr. Mark Spieth of
> #1104, who might be interested in adding AC-3 re-encoding support).
> However, I will admit that I have a few higher priority things to do
> first--such as build and set up my 5.1 (or 7.1) channel speaker system.
> (In other words, it might take a bit as it's pretty low priority for
> me--especially now since I don't have a surround speaker system.)
> However, once I write the code it will do properly what #1105 (
> http://svn.mythtv.org/trac/ticket/1105 ) and #1598 (
> http://svn.mythtv.org/trac/ticket/1598 ) and #1608 (
> http://svn.mythtv.org/trac/ticket/1608 ) tried to do. In the meantime,
> those with auto-detecting receivers (and extremely nice sound cards)
> should have it easy (and, like I said, most receivers auto-detect just
> fine--the patch would just minimize the pops/clicks as the receiver
> switches modes). Then again, I may find a way to get an HDMI 1.3+ audio
> connection so I can send 8 channels of 192kHz 24-bit uncompressed PCM
> audio via a digital link (and avoid the whole AC-3 generational loss).
> (Note, this probably helps you to infer the kind of timeline I'm talking
> about for writing this code.)
>
> Of course, if you're one of the lucky ones who has a sound card on which
> the manufacturer decided to connect the discrete IEC958 input (and that
> supports 32kHz passthrough), there's no reason any useful program should
> ever force a user to use a cryptic configuration string like
> "ALSA:iec958:AES0=0x06,AES1=0x82,AES2=0x00,AES3=0x03". Instead,
> wouldn't it be nice to be able to put that information somewhere where
> it could be reused in any application using a nice, simple-to-remember
> human-readable-and-understandable name? /That/ is the entire reason for
> an ALSA configuration file. Therefore, it makes no sense to say, "You
> don't need an ALSA configuration file." Really, I don't need Myth,
> either. I could just type a bunch of cryptic commands at the console
> that create cron/at jobs to execute the commands required to set up
> capture cards and record programs (I'm guessing it would take about 42
> lines of Perl code ;). Myth--like an ALSA configuration file--is meant
> to make the user experience a little bit more enjoyable.
>
> So you could, instead, put the above configuration information into an
> ALSA configuration file. Something like the bit at the bottom of this
> post would allow you to specify "ALSA:passthru32k" for a 32-kHZ AC-3
> passthrough device. Note, however, that I doubt this will "fix" issues
> with 32kHz passthrough for very many people since most are probably
> having issues due to lack of support from the card.
>
> Show me a sound configuration problem and I'll show you a sound
> configuration problem that can be fixed with ALSA configuration
> files... Unfortunately, people hate what they don't understand, so they
> love to say, "It's not an ALSA configuration file problem," or "This
> [ALSA configuration file] is not required on Fedora Core 5 and 6
> systems," or "If you are using a version of ALSA newer than 1.0.12 --
> <supposedly authoritative source> states that for most uses an .asoundrc
> is not necessary."
>
> I've given up on trying to fix the completely broken Wiki page on
> Configuring Digital Sound (
> http://www.mythtv.org/wiki/index.php/Configuring_Digital_Sound ) because
> people think that just because something worked for them, they can make
> an authoritative statement about proper configuration. I also wholly
> agree with Bruce Markey's dislike of people's posting his words to the
> wiki as the Configuring Digital Sound page was created by copy/pasting
> my words from one of my posts directed at a specific set of users having
> a specific issue with 5.1-channel analog audio on the NFORCE2 and
> explaining why it wasn't working by explaining what they were doing
> incorrectly with the ALSA configuration files. When the info was
> copied, the words were attributed to me--which was perfectly reasonable
> at the time because I actually said them. Then, a lot of people started
> changing the page--including words attributed to me--without changing
> the attribution. Since I never really looked at the wiki for the first
> 6 months, I was "credited" with a /lot/ of inaccurate information until
> I finally took my name out of the page (and fixed some of the
> inaccuracies and removed the "how to understand and write an ALSA
> configuration" part (leaving a link to my post) since no one read
> it--instead just copying the example and proclaiming it either works or
> doesn't). But, I haven't really touched the page since then, and doing
> so isn't worth my time as anything I correct would tend to be
> uncorrected again--if not where I corrected it, in some other comment
> somewhere else on the page or on some other page (i.e. someone makes a
> new page to say what they want because their "opinion" differs from the
> existing page).
>
> So, basically, I've been ignoring the discussion of sound configuration
> for quite some time because it's a very complex issue when you realize
> the vast number of sound cards out there and, although they use a
> limited number of chips--after all, there aren't that many ALSA
> drivers--those chips are hooked up in /very/ different ways, requiring
> very different configurations, especially when you factor in the various
> permutations of sound card/receiver combos (which can also have a big
> effect on perceived usability). And, you may have noticed, I can get a
> bit spun-up over it, too. Unfortunately, it seems most don't care to
> learn how things work or even how their equipment works (so they can
> figure out their own proper configuration) but instead want a
> configuration they can read off a wiki page. And, what's worse, once
> they figure out something that works for their system and audio files,
> they spread it around as "universally" authoritative configuration help.
>
> The only reason I responded to this e-mail was your insistence that it's
> not an ALSA configuration issue and your mentioning me as the guy who
> always says that sound can be fixed with the ALSA configuration files.
> I'll admit that you were pretty much right on the second--I always say
> ALSA configuration issues can be fixed with ALSA configuration
> files--and I stand by my opinion (and would actually go so far as to say
> ALSA configuration issues /should/ be fixed with ALSA configuration
> files). Wow. You're still reading this? It just so happens that most
> sound issues (and many playback issues) are caused by broken ALSA
> configurations. Some, however, may be caused by users trying to get
> their hardware to do things it can't do (like play 32kHz AC-3 audio via
> passthrough)--or, put another (less accusatory) way, because of
> broken/incapable sound cards.
>
> The reason I took forever to respond to the e-mail is because, well, it
> took forever to find enough free time to write it (just like--I'm sure
> you're thinking--it took forever to read it). And, it was very low
> priority because I had been assured that your issue had nothing to do
> with ALSA configuration ;), and besides, I've been accused of being an
> ALSA-configuration-file zealot and don't want to feed the rumors.
>
> Mike "extra-wordy ALSA-configuration-file zealot" Dean
>
> Example ALSA conf fragment for a sound card that pulls IEC958 data from
> a PCM input where the "digital-hw" device is set up to properly output
> PCM via the digital output.
>
> This fragment relies on the rest of the ALSA configuration file at
> http://www.mythtv.org/wiki/index.php/Configuring_Digital_Sound#Setting_up_ALSA.27s_.asoundrc.2C_Properly
> and should be appended to the end of the config file. The only devices
> that should be used by the user are "passthru32k", "passthru44k", and
> "passthru48k". Using this fragment, the user does not even have to
> worry about setting the IEC958 settings on the card. Note that the
> passthru32k and passthru44k are likely to work the same as passthru48k
> (i.e. the sound card most likely only allows 48kHz AC-3 passthrough and
> will ignore the rate specified in the IEC958 status bits, so the user
> should specify "ALSA:passthru48k" as Myth's "Passthrough output device"
> just so the name is more "correct" as to the sound card's
> capabilities). This fragment will /only/ work with sound cards without
> a discrete IEC958 input that pull IEC958 input from a PCM input (which
> likely only support 48kHz passthrough)!
>
> # Use the ALSA device name "passthru32k" for 32kHz encoded audio (i.e. AC-3,
> # DTS, ...) passthrough.
> pcm.passthru32k {
> type plug
> slave.pcm "passthru:AES0=0x06,AES1=0x82,AES2=0x00,AES3=0x03"
> }
>
> # Control device (mixer, etc.) for the card
> ctl.passthru32k {
> type hw
> card 0
> }
>
> # Use the ALSA device name "passthru44k" for 44.1kHz encoded audio (i.e.
> AC-3,
> # DTS, ...) passthrough.
> pcm.passthru44k {
> type plug
> slave.pcm "passthru:AES0=0x06,AES1=0x82,AES2=0x00,AES3=0x00"
> }
>
> # Control device (mixer, etc.) for the card
> ctl.passthru44k {
> type hw
> card 0
> }
>
> # Use the ALSA device name "passthru48k" for 48kHz encoded audio (i.e. AC-3,
> # DTS, ...) passthrough.
> pcm.passthru48k {
> type plug
> slave.pcm "passthru:AES0=0x06,AES1=0x82,AES2=0x00,AES3=0x02"
> }
>
> # Control device (mixer, etc.) for the card
> ctl.passthru48k {
> type hw
> card 0
> }
>
> # Generic passthrough device which accepts IEC958 status bits and sets
> IEC958
> # controls for proper passthrough on a card without a discrete IEC958 input
> # connection that instead pulls non-audio data from PCM
> pcm.passthru {
> @args [ AES0 AES1 AES2 AES3 ]
> @args.AES0 {
> type integer
> }
> @args.AES1 {
> type integer
> }
> @args.AES2 {
> type integer
> }
> @args.AES3 {
> type integer
> }
> type hooks
> slave.pcm "digital-hw"
> hooks.0 {
> type ctl_elems
> hook_args [.
> {
> name "IEC958 Playback Switch"
> lock true
> preserve true
> value true
> }
> {
> name "IEC958 Playback AC97-SPSA"
> lock true
> preserve true
> value 0
> }
> {
> name "IEC958 Playback Source"
> lock true
> preserve true
> value 0
> }
> {
> name "IEC958 Playback Default"
> lock true
> preserve true
> value [ $AES0 $AES1 $AES2 $AES3 ]
> }
> ]
> }
> }
>
> # Control device (mixer, etc.) for the card
> ctl.passthru {
> type hw
> card 0
> }
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: My experience with MythTV annoyances, 0.20.1 version [ In reply to ]
MK> Boy Mike. You seriously have too much time on your hands! ;-)

I just hope that someone takes the time copy that into the wiki!
--
"In the bathtub of history the truth is harder to hold than the soap,
and much more difficult to find." -- Terry Pratchett
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users