(2012-04-08 19:17)Plaguester Wrote: Good. Unmute all the channels in alsamixer. Then use the following until you get one that works:
$ speaker-test -D plughw:0,3
# also try 7, 8, and 9 in place of 3
(2012-04-08 02:06)pumkinut Wrote:
(2012-04-07 23:19)Plaguester Wrote: On a standalone Ubuntu system, this hasn't been needed since 9.04.
Funny, I need an asound.conf file for my brand-spanking-new XBMCbuntu install on an Intel H67 chipset mini-ITX board using the Intel IGP and audio over HDMI. Without the asound.conf I either have to choose correct passthrough audio or menu sounds. With the asound.conf file, I get both.
This thread concerns the NVidia ION chip (Acer Revo). I have no idea what the support level is for the Intel chipsets. I'd be interested to know if you had the same problem with a full Ubuntu install.
Then why did I need an asound.conf file for my integrated GF9300 on a mini-ITX board with Dharma on a minimal Maverick install? And what difference would a minimal vs XBMCBuntu vs full install give? It's mostly just software packages that XBMC does not need. Drivers and dependencies should be installed for each type of setup. A minimal or XBMCBuntu installation should have no problems with hardware that a full installation would solve, unless there is specific software in the GUI that would be needed.
<thread derail over>
If you're going straight to your TV and not passing through to an Audio/Video Receiver, there's no need to check DD or DTS capable receiver options, because your TV is just going to output stereo regardless. Plus, as Plaguester said, the television most likely cannot decode DTS audio (most can't due to licensing issues) and may or may not decode AC3 (Dolby Digital Signals). This is the case with my LG LCD TV, I can feed it AC3 audio and it decodes, passesthrough, and/or downmixes to stereo just fine. DTS just causes static, because it does not have the codecs for DTS decoding.
As for the LAN connection, I tried looking online for the specific PHY for the 3700. All I could find was that it was a Realtek chipset, as are a lot of LAN chipsets now. What you can do is the following. Drop to a terminal window and type in the following:
It could also be eth1, but it's probably eth0. This should tell you what LAN chipset the OS sees and then what driver it's loading. For example on my current laptop:
mint@mint ~ $ dmesg | grep eth0
[ 1.330459] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:26:b9:ce:cb:7f
[ 1.330462] e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
[ 1.330488] e1000e 0000:00:19.0: eth0: MAC: 7, PHY: 8, PBA No: 1004FF-0FF
[ 21.740337] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 24.876885] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
[ 24.877049] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 35.360052] eth0: no IPv6 routers present
Linux is showing that I have an Intel PRO/1000 LAN connection with the e1000e driver loaded. There are a couple of Realtek chipsets where the default driver r8169 is loaded, and causes all kinds of problems. The solution is to revert back to the r8168 driver, but you need to compile and load it yourself. My current HTPC motherboard has the problematic chipset, which is how I found out about it.
You can also see if r8168 or r8169 is loaded by issuing the following command:
This will show you whether or not the 8169 or 8168 drivers are loaded for your LAN adapter.