Page 2 of 2

Posted: Mon Dec 15, 2008 12:10 am
by Pablo
If I understand correctly, the same recording that has working video and working audio on the backend has working video and non-working audio on the frontends. Is that correct?

If so, then it would seem strange that the problem is with the backend. However, it is possible. If it is a problem with the backend, then it would likely be with Myth's streaming protocol, as the streaming of the recording to the fronend is likely the only substantive difference.

If the problem is with the frontends, then it is likely with either mythfrontend's audio configuration or with ALSA's configuration. Have you tried different configuration's of mythfrontend's audio?

Also, what is the audio sample rate of the recordings. Many sound cards only support 48kHz audio without resampling. Some applications do audio resampling for you but mythfrontend does not at this time (it was added to trunk but not to 0.21-fixes). If mythfrontend is configured to use ALSA:default, then ALSA should resample. However, as ALSA configuration is somewhat of a mystery to me, the resampling may not work correctly for all audio devices.

Posted: Mon Dec 15, 2008 1:30 am
by tsarath
Pablo wrote:If I understand correctly, the same recording that has working video and working audio on the backend has working video and non-working audio on the frontends. Is that correct?
Well, I haven't tried with a recordings per say, but just "Live" TV. But since all incoming signals are recorded anyhow this shouldn't matter, so yes, this is correct.
If so, then it would seem strange that the problem is with the backend. However, it is possible. If it is a problem with the backend, then it would likely be with Myth's streaming protocol, as the streaming of the recording to the fronend is likely the only substantive difference.
Yes, after several hours of messing with this and not getting any further, I tend to agree with you. But the backend client uses localhost to connect also, so it shouldn't be the protocol per say.
If the problem is with the frontends, then it is likely with either mythfrontend's audio configuration or with ALSA's configuration. Have you tried different configuration's of mythfrontend's audio?
Yes, been doing that, Ive tried pretty much every combination of output/passthrough device combination on the frontend, no luck. Also checked volume levels etc on both ends via alsamixer as I read frequently they are mute by default, but no go.
Also, what is the audio sample rate of the recordings. Many sound cards only support 48kHz audio without resampling. Some applications do audio resampling for you but mythfrontend does not at this time (it was added to trunk but not to 0.21-fixes). If mythfrontend is configured to use ALSA:default, then ALSA should resample. However, as ALSA configuration is somewhat of a mystery to me, the resampling may not work correctly for all audio devices.
Where is this option set? backend/frontend? In capture card config on the backend (via mythtv-setup) the sampling rate was set to "none" by default, I've changed it to 44/48KHz but didn't make much difference.

I guess it could be the soundcard on the frontend as it's a newer VT1708B based 8 Channel HD Audio card (part of the Nvidia MCP78S chipset) which the backend is using a trusted Soundblaster Live 5.1, sigh...

Posted: Mon Dec 15, 2008 3:03 am
by tsarath
Pablo wrote:A new test build with the VDPAU enabled driver is available: 0.21.0-62b6-nvidia.180.x.x. It includes an updated NVIDIA driver and and updated MPlayer VDPAU patch.
So I tried this image briefly just now. mplayer seems to play the file (sound can be heard) with the "-vo vdpau -vc ffwmv3vdpau" options being used, but nothing is actually displayed on the screen. I tried launching mplayer both from the cli and through the mythtv screen, but same result. I take the options out and myth switches to the video correctly when being played. Not sure what's going on exactly there.

Btw I noticed you've updated ALSA to 1.0.18a, however I still get no sound in LiveTV as the prior b3 build.

Tony

Posted: Tue Dec 16, 2008 6:51 am
by tsarath
Btw I noticed you've updated ALSA to 1.0.18a, however I still get no sound in LiveTV as the prior b3 build.
So after spending most of the weekend trying to unsuccessfully get sound to work with LiveTV I had the novel idea of going through the MythTV docs. It was then I realized the my backend sound wasn't actually working correctly.

Previously I hadn't payed much attention to the video+sound on the backend but after reading this I realized that the they were actually out of sync by a few seconds. My backend is in the attic with <4ft clearance, so not the best place to watch tv.

http://www.mythtv.org/docs/mythtv-HOWTO-7.html and the sound section in http://www.mythtv.org/docs/mythtv-HOWTO-22.html

Once I realized this I knew the sound coming out of the backend wasn't actually getting digitized by myth but being played directly by the soundcard to the speakers. Hence why xawtv worked correctly. This led me to verify the capture settings on the card as per the myth instructions and I'm glad to say I now have sound working with LiveTV as well. So the problem was not on the frontend at all but in the backend soundcard capture settings.

The volume/mute does not work yet on my Myth remote still, but one step forward today is good enough for me. :)

NFS server unreachable in 0.21.0-62b5 (long)

Posted: Tue Dec 30, 2008 8:29 pm
by tsarath
So after spending most of the weekend trying to unsuccessfully get sound to work with LiveTV I had the novel idea of going through the MythTV docs. It was then I realized the my backend sound wasn't actually working correctly.

Previously I hadn't payed much attention to the video+sound on the backend but after reading this I realized that the they were actually out of sync by a few seconds. My backend is in the attic with <4ft clearance, so not the best place to watch tv.

http://www.mythtv.org/docs/mythtv-HOWTO-7.html and the sound section in http://www.mythtv.org/docs/mythtv-HOWTO-22.html

Once I realized this I knew the sound coming out of the backend wasn't actually getting digitized by myth but being played directly by the soundcard to the speakers. Hence why xawtv worked correctly. This led me to verify the capture settings on the card as per the myth instructions and I'm glad to say I now have sound working with LiveTV as well. So the problem was not on the frontend at all but in the backend soundcard capture settings.

The volume/mute does not work yet on my Myth remote still, but one step forward today is good enough for me. :)
So recently having more or less completed my MythTV build based on Minimyth, I decided on a write up in the hope it may prove useful to others. You can find the full write up here.

Tony

Posted: Tue Dec 30, 2008 10:40 pm
by aheybey
Just wanted to chime in that I have also had success with this board and minimyth-0.21.0-62-nvidia.180.18

HDMI video and audio out are working fine.

Took me a while to get audio working, but the following settings are working for me:

BIOS codec setting set to "internal".

# Audio configuration variables.
#
MM_AUDIO_TYPE='digital'
MM_AUDIO_CARD_NUMBER='0'
MM_AUDIO_DEVICE_NUMBER='3'

Thanks to Larry and now Pablo for all the work on minimyth, and to Tony for starting this thread...

Posted: Tue Dec 30, 2008 11:06 pm
by tsarath
aheybey wrote:Just wanted to chime in that I have also had success with this board and minimyth-0.21.0-62-nvidia.180.18

HDMI video and audio out are working fine.

Took me a while to get audio working, but the following settings are working for me:

BIOS codec setting set to "internal".

# Audio configuration variables.
#
MM_AUDIO_TYPE='digital'
MM_AUDIO_CARD_NUMBER='0'
MM_AUDIO_DEVICE_NUMBER='3'
That's good to know as I don't have a receiver yet to test out digital audio. I also posted my full hw setup here in the hardware success section. I currently do have the MCE remote, VFD display and IR blaster that comes with the Hiper HMC-2K53A-A0 case which I'm using working well with minimyth-0.21.0-62b6-nvidia.180.16 I'm currently running.

One annoying issue that I have however is after a reboot, the suspend/wakeup (BIOS ACPI mode set to S3) works for exactly one cycle via the power button on the MCE remote. After the wakeup further suspends will fail on my system. Power button on the chassis still works fine in shutting down the system cleanly however. Not sure if this is a motherboard+Minimyth issue, haven't tried debugging it much as yet. Does your suspend/wakeup work reliably via the remote? I've tried with BIOS setup for S1 but that made it not work at all.

Thanks

Tony

Posted: Wed Dec 31, 2008 2:26 am
by aheybey
tsarath wrote: One annoying issue that I have however is after a reboot, the suspend/wakeup (BIOS ACPI mode set to S3) works for exactly one cycle via the power button on the MCE remote. After the wakeup further suspends will fail on my system. Power button on the chassis still works fine in shutting down the system cleanly however. Not sure if this is a motherboard+Minimyth issue, haven't tried debugging it much as yet. Does your suspend/wakeup work reliably via the remote? I've tried with BIOS setup for S1 but that made it not work at all.
I got the same processor that you did, but went cheaper on the case (hec 7K09) and got 2x1G DRAM just because.

Haven't tried suspend yet at all. My previous frontend (Epia Nehemiah M10000) never had suspend work so frankly it had not even occurred to me to try it.

How do you configure it up for the remote power button to suspend? Can you wake it up again with the remote also?

Posted: Wed Dec 31, 2008 2:47 am
by tsarath
aheybey wrote:
tsarath wrote: One annoying issue that I have however is after a reboot, the suspend/wakeup (BIOS ACPI mode set to S3) works for exactly one cycle via the power button on the MCE remote. After the wakeup further suspends will fail on my system. Power button on the chassis still works fine in shutting down the system cleanly however. Not sure if this is a motherboard+Minimyth issue, haven't tried debugging it much as yet. Does your suspend/wakeup work reliably via the remote? I've tried with BIOS setup for S1 but that made it not work at all.
I got the same processor that you did, but went cheaper on the case (hec 7K09) and got 2x1G DRAM just because.

Haven't tried suspend yet at all. My previous frontend (Epia Nehemiah M10000) never had suspend work so frankly it had not even occurred to me to try it.

How do you configure it up for the remote power button to suspend? Can you wake it up again with the remote also?
I just setup the following in minimyth.conf

MM_LIRC_DRIVER='mceusb2'
MM_LIRC_KERNEL_MODULE='lirc_mceusb2'
MM_LIRC_SLEEP_ENABLED='yes'
MM_LIRC_WAKEUP_ENABLED='yes'

Wakeup via the remote does work on my system for one suspend and wakeup cycle, but as I mentioned, after that it'll fail to go into suspend again till a subsequent reboot. I also got the power, mute and volume controls to work via the IR blaster with the following in minimyth.conf setting. SONY_RM-Y191 is the lircd.conf definition for my TV remote.

MM_EXTERNAL_POWER_OFF='/usr/bin/irsend SEND_ONCE SONY_RM-Y191 Power'
MM_EXTERNAL_VOLUME_DOWN='/usr/bin/irsend SEND_ONCE SONY_RM-Y191 VolDown'
MM_EXTERNAL_VOLUME_UP='/usr/bin/irsend SEND_ONCE SONY_RM-Y191 VolUp'
MM_EXTERNAL_VOLUME_MUTE='/usr/bin/irsend SEND_ONCE SONY_RM-Y191 Muting'

I'll look into the suspend issue when I get a chance, it's almost working, the wake-up process must mess up something to cause the subsequent suspend to fail I'm guessing.

Tony

Posted: Wed Dec 31, 2008 5:08 am
by Pablo
I have one motherboard (an ASUS M2NPV-VM) that did this until I updated to a newer BIOS version.

My experience is that BIOS ACPI compliance is poor. It appears that if your motherboard BIOS boots Windows then you can claim that you support ACPI. For example, the DSDTs provided by many motherboards fail to comply with the standard and do not even pass when checked with the utilities that are freely provide by Intel.

Posted: Wed Dec 31, 2008 8:25 am
by tsarath
Pablo wrote:I have one motherboard (an ASUS M2NPV-VM) that did this until I updated to a newer BIOS version.

My experience is that BIOS ACPI compliance is poor. It appears that if your motherboard BIOS boots Windows then you can claim that you support ACPI. For example, the DSDTs provided by many motherboards fail to comply with the standard and do not even pass when checked with the utilities that are freely provide by Intel.
Thanks, there is one newer BIOS release to the one I'm currently using(0903), but it doesn't seem to have any ACPI related fixes. Plus I haven't had the chance to capture any more details on the issue but I'll try. It's never run Windows of course as it's diskless.

Tony

Posted: Fri Jan 02, 2009 3:25 pm
by aheybey
tsarath wrote:
aheybey wrote: Haven't tried suspend yet at all. My previous frontend (Epia Nehemiah M10000) never had suspend work so frankly it had not even occurred to me to try it.

How do you configure it up for the remote power button to suspend? Can you wake it up again with the remote also?
I just setup the following in minimyth.conf

MM_LIRC_DRIVER='mceusb2'
MM_LIRC_KERNEL_MODULE='lirc_mceusb2'
MM_LIRC_SLEEP_ENABLED='yes'
MM_LIRC_WAKEUP_ENABLED='yes'

Wakeup via the remote does work on my system for one suspend and wakeup cycle, but as I mentioned, after that it'll fail to go into suspend again till a subsequent reboot. I also got the power, mute and volume controls to work via the IR blaster with the following in minimyth.conf setting. SONY_RM-Y191 is the lircd.conf definition for my TV remote.

MM_EXTERNAL_POWER_OFF='/usr/bin/irsend SEND_ONCE SONY_RM-Y191 Power'
MM_EXTERNAL_VOLUME_DOWN='/usr/bin/irsend SEND_ONCE SONY_RM-Y191 VolDown'
MM_EXTERNAL_VOLUME_UP='/usr/bin/irsend SEND_ONCE SONY_RM-Y191 VolUp'
MM_EXTERNAL_VOLUME_MUTE='/usr/bin/irsend SEND_ONCE SONY_RM-Y191 Muting'

I'll look into the suspend issue when I get a chance, it's almost working, the wake-up process must mess up something to cause the subsequent suspend to fail I'm guessing.
Ah, I have a home-brew LIRC receiver on the serial port, not USB. So no wakeup by the remote for me.

On a slightly different but related issue, just in case anyone else is searching for an answer:

I am using a One-For-All URC-6131 remote, programmed following the directions here. The lircd.conf from that link worked fine with my Epia M10000, but for reasons I do not understand does *not* work with the new M3N78-VM. Making my own from scratch with irrecord did not work (irrecord would say "Something went wrong" when trying to record the individual buttons). Then I tried starting with LIRC's generic RC-5.conf file, and that sort-of worked except that you would have to press a button twice for lircd to see it. Finally, I removed the line:

toggle_bit_mask 0x0

and added

toggle_bit 2

to the resulting lircd.conf, and that worked.

andrew
[/img]