Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Dev

Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding

 

 

MythTV dev RSS feed   Index | Next | Previous | View Threaded


jppoet at gmail

Nov 9, 2008, 5:06 PM

Post #1 of 23 (6592 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding

On Sun, Nov 9, 2008 at 5:54 PM, MythTV <mythtv [at] cvs> wrote:
> #5900: AO: Generalise upmix and AC-3 encoding
> ------------------------------+---------------------------------------------
> Reporter: foobum [at] gmail | Owner: ijr
> Type: patch | Status: new
> Priority: minor | Milestone: unknown
> Component: mythtv | Version: head
> Severity: medium | Mlocked: 0
> ------------------------------+---------------------------------------------
> This patch generalises the upmix / AC-3 (re)encode functionality. Main
> thing is that it makes upmix and encode to DD5.1 work.
>
> Also:
>
> * Turn on resampler where sr != 48k ![1] [[BR]]

This is optional, right?!?!

I paid extra money for a soundcard that actually does 44.1KHz
correctly, so I could have "bit perfect" audio.


John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


foobum at gmail

Nov 9, 2008, 5:23 PM

Post #2 of 23 (6476 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

2008/11/10 John P Poet <jppoet [at] gmail>

> > * Turn on resampler where sr != 48k ![1] [[BR]]
>
> This is optional, right?!?!
>
> I paid extra money for a soundcard that actually does 44.1KHz
> correctly, so I could have "bit perfect" audio.
>

At the moment it's not because recent versions of ALSA resample to 48k by
default anyway.
The SRC we use is *much* nicer than the linear interpolation that ALSA
inflicts.

Besides, many cards don't do 44.1k - ideally we'd know what the card
supports before we open it,
but it's a bit messy to implement and the SRC gives a SNR of 97dB at 97% bw
anyway. I really didn't
want to add any additional config, but happy to consider another way of
doing it..


jppoet at gmail

Nov 9, 2008, 6:14 PM

Post #3 of 23 (6467 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

On Sun, Nov 9, 2008 at 6:23 PM, foo bar <foobum [at] gmail> wrote:
> 2008/11/10 John P Poet <jppoet [at] gmail>
>>
>> > * Turn on resampler where sr != 48k ![1] [[BR]]
>>
>> This is optional, right?!?!
>>
>> I paid extra money for a soundcard that actually does 44.1KHz
>> correctly, so I could have "bit perfect" audio.
>
> At the moment it's not because recent versions of ALSA resample to 48k by
> default anyway.
> The SRC we use is *much* nicer than the linear interpolation that ALSA
> inflicts.
>
> Besides, many cards don't do 44.1k - ideally we'd know what the card
> supports before we open it,
> but it's a bit messy to implement and the SRC gives a SNR of 97dB at 97% bw
> anyway. I really didn't
> want to add any additional config, but happy to consider another way of
> doing it..

Modern ALSA will automatically resample to 48, but only for cards that
need it. Mine does not.

How are you defining SNR? There is no way you can resample a 44.1KHz
source into 48KHz and have it be "accurate". To my ears, resampling
like that always results in a least some sibilance and tends to muddy
the hight frequencies.

Assuming this gets committed to myth trunk "as is", I hope you can
provide me with a patch to disable that "feature" . I already compile
myth with my own patches added on, so that is not a problem for me.

Thanks,

John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


kormoc at gmail

Nov 9, 2008, 6:25 PM

Post #4 of 23 (6462 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

On Sun, Nov 9, 2008 at 6:14 PM, John P Poet <jppoet [at] gmail> wrote:
> Assuming this gets committed to myth trunk "as is", I hope you can
> provide me with a patch to disable that "feature" . I already compile
> myth with my own patches added on, so that is not a problem for me.

Edit the patch files, change the + to - and the - to + and there you
go, you have a reversed patch, or use svn merge to unmerge that
changeset, svn diff > file.patch, all of which you can do on your
own...
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


jppoet at gmail

Nov 9, 2008, 6:38 PM

Post #5 of 23 (6471 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

On Sun, Nov 9, 2008 at 7:25 PM, Rob Smith <kormoc [at] gmail> wrote:
> On Sun, Nov 9, 2008 at 6:14 PM, John P Poet <jppoet [at] gmail> wrote:
>> Assuming this gets committed to myth trunk "as is", I hope you can
>> provide me with a patch to disable that "feature" . I already compile
>> myth with my own patches added on, so that is not a problem for me.
>
> Edit the patch files, change the + to - and the - to + and there you
> go, you have a reversed patch, or use svn merge to unmerge that
> changeset, svn diff > file.patch, all of which you can do on your
> own...

Yeah, I just mean *that* feature of the patch. It would be nice if
foo could identify which part of the patch I would need to revert.
The rest of it could be useful.

John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


foobum at gmail

Nov 10, 2008, 11:24 AM

Post #6 of 23 (6449 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

> Modern ALSA will automatically resample to 48, but only for cards
> that need it. Mine does not.

Modern ALSA does software mixing by default and resamples to 48k
before doing so.
That the card supports the original sample rate makes no difference.

> How are you defining SNR? There is no way you can resample a
> 44.1KHz source into 48KHz and have it be "accurate".

I would venture that it's inaudibly inaccurate.
Details of the resampler, including SNR definition, here:
http://www.mega-nerd.com/SRC/
We use SRC_SINC_BEST_QUALITY.

> Yeah, I just mean *that* feature of the patch. It would be nice if
> foo could identify which part of the patch I would need to revert.
> The rest of it could be useful.

Assuming your card/receiver can do both 44.1k AC-3 and PCM, the
following should do what you want:

--- libs/libmyth/audiooutputbase.cpp 2008-11-10 19:08:28.000000000 +0000
+++ libs/libmyth/audiooutputbase.cpp 2008-11-10 19:09:41.000000000 +0000
@@ -252,7 +252,7 @@
{
VERBOSE(VB_AUDIO, LOC + "Creating AC-3 Encoder");
encoder = new AudioOutputDigitalEncoder();
- if (!encoder->Init(CODEC_ID_AC3, 448000, 48000,
+ if (!encoder->Init(CODEC_ID_AC3, 448000, audio_samplerate,
configured_audio_channels, audio_reenc))
{
VERBOSE(VB_AUDIO, LOC + "Can't create AC-3 encoder");
@@ -272,7 +272,7 @@

// Always resample to 48k - many cards can't do anything else
// and ALSA will do it with linear interpolation (yuk) if we don't anyway
- if (audio_samplerate != 48000)
+ if (0)
{
int error;
audio_samplerate = 48000;
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


jppoet at gmail

Nov 10, 2008, 11:45 AM

Post #7 of 23 (6452 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

On Mon, Nov 10, 2008 at 12:24 PM, foo bar <foobum [at] gmail> wrote:
>> Modern ALSA will automatically resample to 48, but only for cards
>> that need it. Mine does not.
>
> Modern ALSA does software mixing by default and resamples to 48k
> before doing so.
> That the card supports the original sample rate makes no difference.
>
>> How are you defining SNR? There is no way you can resample a
>> 44.1KHz source into 48KHz and have it be "accurate".
>
> I would venture that it's inaudibly inaccurate.
> Details of the resampler, including SNR definition, here:
> http://www.mega-nerd.com/SRC/
> We use SRC_SINC_BEST_QUALITY.
>
>> Yeah, I just mean *that* feature of the patch. It would be nice if
>> foo could identify which part of the patch I would need to revert.
>> The rest of it could be useful.
>
> Assuming your card/receiver can do both 44.1k AC-3 and PCM, the
> following should do what you want:
>
> --- libs/libmyth/audiooutputbase.cpp 2008-11-10 19:08:28.000000000 +0000
> +++ libs/libmyth/audiooutputbase.cpp 2008-11-10 19:09:41.000000000 +0000
> @@ -252,7 +252,7 @@
> {
> VERBOSE(VB_AUDIO, LOC + "Creating AC-3 Encoder");
> encoder = new AudioOutputDigitalEncoder();
> - if (!encoder->Init(CODEC_ID_AC3, 448000, 48000,
> + if (!encoder->Init(CODEC_ID_AC3, 448000, audio_samplerate,
> configured_audio_channels, audio_reenc))
> {
> VERBOSE(VB_AUDIO, LOC + "Can't create AC-3 encoder");
> @@ -272,7 +272,7 @@
>
> // Always resample to 48k - many cards can't do anything else
> // and ALSA will do it with linear interpolation (yuk) if we don't anyway
> - if (audio_samplerate != 48000)
> + if (0)
> {
> int error;
> audio_samplerate = 48000;

Thank you!


John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


dbadia at gmail

Nov 10, 2008, 7:27 PM

Post #8 of 23 (6453 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

On Mon, Nov 10, 2008 at 2:45 PM, John P Poet <jppoet [at] gmail> wrote:

> On Mon, Nov 10, 2008 at 12:24 PM, foo bar <foobum [at] gmail> wrote:
>
> >
> > Assuming your card/receiver can do both 44.1k AC-3 and PCM, the
> > following should do what you want:
> >
> > --- libs/libmyth/audiooutputbase.cpp 2008-11-10 19:08:28.000000000
> +0000
> > +++ libs/libmyth/audiooutputbase.cpp 2008-11-10 19:09:41.000000000
> +0000
> > @@ -252,7 +252,7 @@
> > {
> > VERBOSE(VB_AUDIO, LOC + "Creating AC-3 Encoder");
> > encoder = new AudioOutputDigitalEncoder();
> > - if (!encoder->Init(CODEC_ID_AC3, 448000, 48000,
> > + if (!encoder->Init(CODEC_ID_AC3, 448000, audio_samplerate,
> > configured_audio_channels, audio_reenc))
> > {
> > VERBOSE(VB_AUDIO, LOC + "Can't create AC-3 encoder");
> > @@ -272,7 +272,7 @@
> >
> > // Always resample to 48k - many cards can't do anything else
> > // and ALSA will do it with linear interpolation (yuk) if we don't
> anyway
> > - if (audio_samplerate != 48000)
> > + if (0)
> > {
> > int error;
> > audio_samplerate = 48000;
>
>
I'm also doing the whole "bit perfect audio" thing. So, if I'm
understanding correctly, when I upgrade to head/next myth release I will
need to apply the above patch (which removes one of the features of the
original patch) to continue getting 44.1KHz output through my soundcard?

Dave


foobum at gmail

Nov 11, 2008, 9:32 AM

Post #9 of 23 (6402 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

2008/11/11 Dave Badia <dbadia [at] gmail>:
> I'm also doing the whole "bit perfect audio" thing. So, if I'm
> understanding correctly, when I upgrade to head/next myth release I will
> need to apply the above patch (which removes one of the features of the
> original patch) to continue getting 44.1KHz output through my soundcard?

This is configurable in the latest version of the patch - if you're
confident that ALSA isn't going to resample (twice) and have
appropriate hardware you can add a setting 'DisableResampler' with
value 1 to the db.

For the vast majority it's far better that we resample - SRC anywhere
else in the chain (ALSA, card) would be done with a SNR much less than
a *worst case* 97dB..

To set the setting:

echo "insert into settings values ('DisableResampler', 0, '<hostname
of frontend>')" | mysql -u mythtv -p mythconverg
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mythtv at colin

Nov 11, 2008, 12:01 PM

Post #10 of 23 (6415 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

Rob Smith wrote:
> Edit the patch files, change the + to - and the - to + and there you
> go, you have a reversed patch,

Or just use patch -R....

Col


--

Colin Guthrie
myth(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mythtv at colin

Nov 11, 2008, 12:08 PM

Post #11 of 23 (6414 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

foo bar wrote:
> 2008/11/11 Dave Badia <dbadia [at] gmail>:
>> I'm also doing the whole "bit perfect audio" thing. So, if I'm
>> understanding correctly, when I upgrade to head/next myth release I will
>> need to apply the above patch (which removes one of the features of the
>> original patch) to continue getting 44.1KHz output through my soundcard?
>
> This is configurable in the latest version of the patch - if you're
> confident that ALSA isn't going to resample (twice) and have
> appropriate hardware you can add a setting 'DisableResampler' with
> value 1 to the db.
>
> For the vast majority it's far better that we resample - SRC anywhere
> else in the chain (ALSA, card) would be done with a SNR much less than
> a *worst case* 97dB..
>
> To set the setting:
>
> echo "insert into settings values ('DisableResampler', 0, '<hostname
> of frontend>')" | mysql -u mythtv -p mythconverg

Can this be configured by a sound output class (e.g. the sound output
pulseaudio class from cal's patch)? In this output class you'd probably
want to enforce no resampling programatically and not rely on having to
set a setting too.

Col

--

Colin Guthrie
myth(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


foobum at gmail

Nov 11, 2008, 1:13 PM

Post #12 of 23 (6391 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

2008/11/11 Colin Guthrie <mythtv [at] colin>:
> Can this be configured by a sound output class (e.g. the sound output
> pulseaudio class from cal's patch)? In this output class you'd probably
> want to enforce no resampling programatically and not rely on having to
> set a setting too.

Nope, but only because disable_resampler is private.

A quick glance suggests that PA plan to move to using 48k internally anyway.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mythtv at colin

Nov 11, 2008, 1:35 PM

Post #13 of 23 (6418 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

foo bar wrote:
> 2008/11/11 Colin Guthrie <mythtv [at] colin>:
>> Can this be configured by a sound output class (e.g. the sound output
>> pulseaudio class from cal's patch)? In this output class you'd probably
>> want to enforce no resampling programatically and not rely on having to
>> set a setting too.
>
> Nope, but only because disable_resampler is private.
>
> A quick glance suggests that PA plan to move to using 48k internally anyway.

Yeah it will be but you'd still not want to do any resampling in myth
when using pulse. Pulse has it's own resampling framework and it would
make sense IMO to use the same resampler system-wide, hence why you'd
want to disable the resampling in myth and off-load this task to pulse
(if you're using the native pulse output obviously - this wouldn't work
if you go via the alsa->pulse plugin (well it kinda would, but you'd
need the aforementioned setting to disabled the resampler!)).

Col

--

Colin Guthrie
myth(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


foobum at gmail

Nov 11, 2008, 2:18 PM

Post #14 of 23 (6400 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

2008/11/11 Colin Guthrie <mythtv [at] colin>:
> Yeah it will be but you'd still not want to do any resampling in myth
> when using pulse. Pulse has it's own resampling framework and it would
> make sense IMO to use the same resampler system-wide, hence why you'd
> want to disable the resampling in myth and off-load this task to pulse
> (if you're using the native pulse output obviously - this wouldn't work
> if you go via the alsa->pulse plugin (well it kinda would, but you'd
> need the aforementioned setting to disabled the resampler!)).

The best resampler available in PA is the same as myth's; probably
doesn't matter much where it's done.

Anyway, I'll make disable_resampler protected so that children can set
it (in their constructor presumably) if they want to.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


jppoet at gmail

Nov 11, 2008, 11:49 PM

Post #15 of 23 (6403 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

On Tue, Nov 11, 2008 at 10:32 AM, foo bar <foobum [at] gmail> wrote:
> 2008/11/11 Dave Badia <dbadia [at] gmail>:
>> I'm also doing the whole "bit perfect audio" thing. So, if I'm
>> understanding correctly, when I upgrade to head/next myth release I will
>> need to apply the above patch (which removes one of the features of the
>> original patch) to continue getting 44.1KHz output through my soundcard?
>
> This is configurable in the latest version of the patch - if you're
> confident that ALSA isn't going to resample (twice) and have
> appropriate hardware you can add a setting 'DisableResampler' with
> value 1 to the db.
>
> For the vast majority it's far better that we resample - SRC anywhere
> else in the chain (ALSA, card) would be done with a SNR much less than
> a *worst case* 97dB..
>
> To set the setting:
>
> echo "insert into settings values ('DisableResampler', 0, '<hostname
> of frontend>')" | mysql -u mythtv -p mythconverg

Just as a note....

A couple of years ago I really wanted to just be able to use the
on-board sound in my mythfrontend. While it sounded fine for TV and
Movies, there was a noticeable degradation when playing music. At the
time I was an audiotron user, and the difference in audio quality was
obvious.

After some research I went out and bought a ice1712 based sound card.
At the time is was a PITA to get working, but once I did, it pretty
much solved the audio quality problem. To get it working, I had to
use a custom .asoundrc file.

With modern ALSA, my ice1712 based sound card is just plug-n-play. No
.asoundrc file necessary at all. Foo managed to make me paranoid that
ALSA might actually be re-sampling 44.1KHz into 48KHz, and maybe I had
not noticed the drop in quality - since I have not used my audiotron
in so long. A little searching and I found this:

http://alsa.opensrc.org/index.php/DigitalOut

The page he links to in that article has 44.1KHz DTS encoded wave
files. If you try and play them on a soundcard that is being
re-sampled to 48KHz, you apparently get static. On my system, I get
the appropriate sound effects, which is suppose to prove that I am
getting bit-perfect 44.1KHz audio. If someone with a soundcard that
does require 48KHz could try this test, I would appreciate
confirmation that the test is valid.

John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


asherml at gmail

Nov 12, 2008, 6:42 AM

Post #16 of 23 (6373 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

I just tried both the surround test and Norrlanda clips, and they
played correctly when using my .asoundrc to sample to 48khz, but
failed with no sound and underrun messages without the .asoundrc.

I don't have a 48KHz clip to try to make sure it can play ANYTHING
without the .asoundrc.

The command I used to play it was:

aplay -D iec958:CARD=NVidia,DEV=0 <wavefile>

My receiver still saw "DTS 5.1" audio with the .asoundrc. My
motherboard is a MSI Media Live (which uses an RealTek ALC883 for
sound).

Let me know if you want me to try anything else.

David.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


foobum at gmail

Nov 12, 2008, 1:52 PM

Post #17 of 23 (6351 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

On 12/11/2008, John P Poet <jppoet [at] gmail> wrote:
> With modern ALSA, my ice1712 based sound card is just plug-n-play. No
> .asoundrc file necessary at all. Foo managed to make me paranoid that
> ALSA might actually be re-sampling 44.1KHz into 48KHz, and maybe I had
> not noticed the drop in quality - since I have not used my audiotron
> in so long.

The test you outlined just shows that the card and receiver support
spdif clocked at 44.1k. It doesn't tell you anything about ALSA's
resampling or lack thereof.

ALSA will, by default, resample pcm (i.e. samples that you send to the
main device rather than AC3/DTS that you send to the iec958/spdif
device) that's not 48k. If we request 44.1k it presumably resamples
again after mixing, etc - ugh. With no asoundrc, this is probably
happening to you. I guess using a hw device (hw0:0 etc) prevents this.

The SRC we use honestly makes no audible difference (and my ears
aren't very old :). But if you really want "bit perfect" (digitally
sampled, probably lossy compressed) audio and don't mind no sw mixing
make sure that you are using a hw device for your main device.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mythtv at colin

Nov 12, 2008, 2:20 PM

Post #18 of 23 (6358 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

foo bar wrote:
> The best resampler available in PA is the same as myth's; probably
> doesn't matter much where it's done.

True, but if your system is not a dedicated myth-box then I think it's
nice that you can define the resampling method in a central place that
works in all apps, rather than setting up all apps individually in their
own way.

> Anyway, I'll make disable_resampler protected so that children can set
> it (in their constructor presumably) if they want to.

Cool :)

Col


--

Colin Guthrie
myth(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


jppoet at gmail

Nov 12, 2008, 10:58 PM

Post #19 of 23 (6356 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

On Wed, Nov 12, 2008 at 2:52 PM, foo bar <foobum [at] gmail> wrote:
> On 12/11/2008, John P Poet <jppoet [at] gmail> wrote:
>> With modern ALSA, my ice1712 based sound card is just plug-n-play. No
>> .asoundrc file necessary at all. Foo managed to make me paranoid that
>> ALSA might actually be re-sampling 44.1KHz into 48KHz, and maybe I had
>> not noticed the drop in quality - since I have not used my audiotron
>> in so long.
>
> The test you outlined just shows that the card and receiver support
> spdif clocked at 44.1k. It doesn't tell you anything about ALSA's
> resampling or lack thereof.
>
> ALSA will, by default, resample pcm (i.e. samples that you send to the
> main device rather than AC3/DTS that you send to the iec958/spdif
> device) that's not 48k. If we request 44.1k it presumably resamples
> again after mixing, etc - ugh. With no asoundrc, this is probably
> happening to you. I guess using a hw device (hw0:0 etc) prevents this.
>
> The SRC we use honestly makes no audible difference (and my ears
> aren't very old :). But if you really want "bit perfect" (digitally
> sampled, probably lossy compressed) audio and don't mind no sw mixing
> make sure that you are using a hw device for your main device.

So, you are saying that if I do:

aplay -D iec958 music.wav

where music.wav is encoded at 44.1KHz, that alsa will convert that to
48KHz, then back to 44.1KHz before sending it to my receiver, just so
it can "mix"? That is ugly. Guess I will have to craft up a
asound.conf file to tell it not to do that. Been a while since I
have had to do that -- gonna need a refresher.

My receiver definitely says it is receiving a 44.1KHz signal, so I
know the sound card is delivering it at the correct rate.

Thanks,

John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


cal at graggrag

Nov 12, 2008, 11:48 PM

Post #20 of 23 (6342 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

John P Poet wrote:
> On Wed, Nov 12, 2008 at 2:52 PM, foo bar <foobum [at] gmail> wrote:
>> On 12/11/2008, John P Poet <jppoet [at] gmail> wrote:
>>> With modern ALSA, my ice1712 based sound card is just plug-n-play. No
>>> .asoundrc file necessary at all. Foo managed to make me paranoid that
>>> ALSA might actually be re-sampling 44.1KHz into 48KHz, and maybe I had
>>> not noticed the drop in quality - since I have not used my audiotron
>>> in so long.
>> The test you outlined just shows that the card and receiver support
>> spdif clocked at 44.1k. It doesn't tell you anything about ALSA's
>> resampling or lack thereof.
>>
>> ALSA will, by default, resample pcm (i.e. samples that you send to the
>> main device rather than AC3/DTS that you send to the iec958/spdif
>> device) that's not 48k. If we request 44.1k it presumably resamples
>> again after mixing, etc - ugh. With no asoundrc, this is probably
>> happening to you. I guess using a hw device (hw0:0 etc) prevents this.
>>
>> The SRC we use honestly makes no audible difference (and my ears
>> aren't very old :). But if you really want "bit perfect" (digitally
>> sampled, probably lossy compressed) audio and don't mind no sw mixing
>> make sure that you are using a hw device for your main device.
>
> So, you are saying that if I do:
>
> aplay -D iec958 music.wav
>
> where music.wav is encoded at 44.1KHz, that alsa will convert that to
> 48KHz, then back to 44.1KHz before sending it to my receiver, just so
> it can "mix"? That is ugly. Guess I will have to craft up a
> asound.conf file to tell it not to do that. Been a while since I
> have had to do that -- gonna need a refresher.

It belongs in AudioOutputALSA, not asound.conf. If you explicitly don't
want alsa to do any resampling, you simply have to tell it that during the pcm
initialization. Unless told otherwise, alsa defaults to "yes, I'll accommodate
your crappy soundcard but I'll have to resample".

A question I'm fuzzy on on is just when "no alsa resample!" is required/desired?
Always? Sometimes only, depending on ... what? Putting such functionality into
AudioOutputALSA is trivial (the current one flies with the default), but what's
the logic around it?

> My receiver definitely says it is receiving a 44.1KHz signal, so I
> know the sound card is delivering it at the correct rate.

Nice to hear!

cheers, Cal
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


foobum at gmail

Nov 13, 2008, 1:44 AM

Post #21 of 23 (6336 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

2008/11/13 John P Poet <jppoet [at] gmail>:
> So, you are saying that if I do:
>
> aplay -D iec958 music.wav
>
> where music.wav is encoded at 44.1KHz, that alsa will convert that to
> 48KHz, then back to 44.1KHz before sending it to my receiver, just so
> it can "mix"? That is ugly. Guess I will have to craft up a
> asound.conf file to tell it not to do that. Been a while since I
> have had to do that -- gonna need a refresher.
>
> My receiver definitely says it is receiving a 44.1KHz signal, so I
> know the sound card is delivering it at the correct rate.

No. I assume iec958 is a straight hw device and that ALSA doesn't do
sw mixing and therefore doesn't resample in that case.

It would resample if you were to do aplay music.wav or aplay -D
default music.wav or aplay -D plughw:x,y music.wav, which is why
resampling in myth is best thing for the majority.

Have you actually tried the SRC in myth?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


lists at glidos

Nov 13, 2008, 3:02 AM

Post #22 of 23 (6321 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

foo bar wrote:
> 2008/11/13 John P Poet <jppoet [at] gmail>:
>> So, you are saying that if I do:
>>
>> aplay -D iec958 music.wav
>>
>> where music.wav is encoded at 44.1KHz, that alsa will convert that to
>> 48KHz, then back to 44.1KHz before sending it to my receiver, just so
>> it can "mix"? That is ugly. Guess I will have to craft up a
>> asound.conf file to tell it not to do that. Been a while since I
>> have had to do that -- gonna need a refresher.
>>
>> My receiver definitely says it is receiving a 44.1KHz signal, so I
>> know the sound card is delivering it at the correct rate.
>
> No. I assume iec958 is a straight hw device and that ALSA doesn't do
> sw mixing and therefore doesn't resample in that case.
>
> It would resample if you were to do aplay music.wav or aplay -D
> default music.wav or aplay -D plughw:x,y music.wav, which is why
> resampling in myth is best thing for the majority.
>
> Have you actually tried the SRC in myth?

I don't know if this is relevant, but I use a .asoundrc file in the
mythtv user's home directory, containing:

pcm.!default {
type plug
slave {
pcm "spdif"
rate 48000
format S16_LE
}
}

That makes mythtv and mplayer output to spdif, with non 48000 content
resampled to 4800.

Cheers,
Paul.

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


stuarta at squashedfrog

Nov 16, 2008, 2:40 AM

Post #23 of 23 (6234 views)
Permalink
Re: [mythtv-commits] Ticket #5900: AO: Generalise upmix and AC-3 encoding [In reply to]

Rob Smith wrote:
> On Sun, Nov 9, 2008 at 6:14 PM, John P Poet <jppoet [at] gmail> wrote:
>> Assuming this gets committed to myth trunk "as is", I hope you can
>> provide me with a patch to disable that "feature" . I already compile
>> myth with my own patches added on, so that is not a problem for me.
>
> Edit the patch files, change the + to - and the - to + and there you
> go, you have a reversed patch, or use svn merge to unmerge that
> changeset, svn diff > file.patch, all of which you can do on your
> own...

patch -R

will save you a lot of editing....

stuart

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

MythTV dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.