+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Linux (https://forum.kodi.tv/forumdisplay.php?fid=52)
+---- Thread: [LINUX] HOW-TO install XBMC for Linux on Ubuntu 8.04 (Hardy) and 8.10 (Intrepid) (/showthread.php?tid=44019)
- olympia - 2009-03-17
l.capriotti Wrote:it's part of the default grub parameters since if you don't perform an "alsactl store" the levels are lost at reboot.
I am a bit confused because the following:
If you set to run setAlsaVolumes by default, then why even need a separate token to be included to the grub parameters, and not just run setAlsaVolumes without any condition?
Thank you for your patience!
ps. I saw the fix already commited for unmuting, thank you for this too!
- lcapriotti - 2009-03-17
olympia Wrote:why even need a separate token to be included to the grub parameters, and not just run setAlsaVolumes without any condition?freedom of choice? I can set the volume and then alsaclt store, and I don't want anything automatic to mess with my settings.
- olympia - 2009-03-17
l.capriotti Wrote:freedom of choice? I can set the volume and then alsaclt store, and I don't want anything automatic to mess with my settings.
OK, so if I understand you correctly
- you set to run setAlsaVolumes by default in Live
- setAlsaVolumes unmute all devices and set volumes to 100% when it runs
- as alsactl store is commented out at the end of the script, these settings are lost at reboot, but automatically re-applied by setAlsaVolumes
- If you are an experienced user and can handle alsa volumes on your own (setting volumes, then save with alsactl store), then you have to remove the token from grub command line, otherwise your saved volumes will be overwritten by setAlsaVolumes.
Is that correct?
- lcapriotti - 2009-03-17
100% correct
- olympia - 2009-03-17
l.capriotti Wrote:As per unmuting, tks for pointing it out, I will commit a fix soon (add unmute to amixer sset cmdline)
Luigi, I am testing it, but realized that it is not unmuting IEC devices.
After a little investigation I found out, that these are not listing pvolume in their capabilities which you are looking for in the script to set volumes.
Nevertheless, if I try amixer sset devicename unmute, it is ok.
So I think we need to look for something else in the script to check if volume set is applicable, but I am unsure for what.
- olympia - 2009-03-18
Changelog:
17/03/2009
- Changed autostart method to start from init.d. Thanks to bobb0 and Luigi
- ashlar - 2009-03-18
Considering the work on the Smoothvideo branch, it might be interesting to have instructions to enable analog out sound, as well as SPDIF.
Check here if you will: http://forum.xbmc.org/showthread.php?p=299714
Cheers!
- olympia - 2009-03-18
ashlar Wrote:Considering the work on the Smoothvideo branch, it might be interesting to have instructions to enable analog out sound, as well as SPDIF.
Check here if you will: http://forum.xbmc.org/showthread.php?p=299714
Cheers!
What do you exactly mean on that?
- sensei73 - 2009-03-18
Thanks Olympia, my setup is up and running thanks to your guide! I just want to help also with the cpu temp, i have a dual-core cpu and the way you grep the temp is not correct here is the real way to do it:
<cputempcommand>echo "$(sensors | grep "Core 0" | sed -e 's/[a-z]*..............\([0-9].\)\..*/\1/') C"</cputempcommand>
at least for dual core!
thanks again
- ashlar - 2009-03-18
olympia Wrote:What do you exactly mean on that?I might have misunderstood the wiki entry, but I gather that the tutorial gives indication for digital audio out only, no analog.
For the Smoothvideo branch to work correctly, analog out is most important. That's what I mean. If you are familiar with Reclock, under Windows, you might understand it better.
- olympia - 2009-03-18
ashlar Wrote:I might have misunderstood the wiki entry, but I gather that the tutorial gives indication for digital audio out only, no analog.
For the Smoothvideo branch to work correctly, analog out is most important. That's what I mean. If you are familiar with Reclock, under Windows, you might understand it better.
I am not a pro on this field, so please explain me how analog out comes to the most important place concerning smoothvideo. When I tried last time, was OK with spdif.
- olympia - 2009-03-18
sensei73 Wrote:Thanks Olympia, my setup is up and running thanks to your guide! I just want to help also with the cpu temp, i have a dual-core cpu and the way you grep the temp is not correct here is the real way to do it:
<cputempcommand>echo "$(sensors | grep "Core 0" | sed -e 's/[a-z]*..............\([0-9].\)\..*/\1/') C"</cputempcommand>
at least for dual core!
thanks again
Yeah, I use exactly the same command, just forgot to update the guide with that. (http://forum.xbmc.org/showpost.php?p=286693&postcount=56)
Anyway it also can differ mobo by mobo. But this version might be more common today.
Thanks!
- ashlar - 2009-03-19
olympia Wrote:I am not a pro on this field, so please explain me how analog out comes to the most important place concerning smoothvideo. When I tried last time, was OK with spdif.Are you aware that there is a Smoothvideo branch being worked on? It's based on the same principles of the Reclock sound renderer under Windows.
It resamples sound so as to keep everything in synch, correcting the minor differences that happen among the system clock, graphic card clock, soundcard clock, etc.
Also, it's capable of slowing down 25fps accelerated material back to its original 24fps (this is a problem in PAL territories).
It can perform the first function with SPDIF if the refresh rate it's really close to optimal, otherwise it has to drop packets and that can be bad. It can't perform the second function with SPDIF, as packets dropped would be unacceptable.
Read here http://forum.xbmc.org/showthread.php?tid=46091
- bobb0 - 2009-03-19
Hey Olympia,
Another modification... this time to the sound configuration.
I followed your setup instructions and successfully used the hdmi device as provided by ALSA. However I soon found a problem that (I'm kind of assuming) is probably affecting a lot of other people....
Whenever I play music (which is naturally 44.1kHz) it was playing at 48kHz. Sacre bleu! Suffice to say it sounded like the singers were on low hits of helium
Investigation into my on-board sound (MCP78S in case you're wondering) reveals 2 codecs:
codec#0:Codec: Realtek ALC883
codec#3:Codec: Nvidia MCP78 HDMI
codec#0 is the "normal" codec used by the system for analog and iec958
codec#3 is for HDMI Audio (which is my point of interest)
when I cat /proc/asound/card0/codec#3 I see that 44.1kHz is not a supported samplerate for the HDMI Audio codec:
PCM:
rates [0xc0]: 48000 88200
bits [0xf]: 8 16 20 24
formats [0x1]: PCM
indeed this is confirmed by the helium voices and /var/tmp/xbmc-xbmc.log
19:24:42 T:3052422976 M:156991488 DEBUG: CALSADirectSound::CALSADirectSound - Channels: 2 - SampleRate: 44100 - SampleBit: 16 - Resample false - Codec - IsMusic true - IsPassthrough false - audioDevice: hdmi
19:24:42 T:3052422976 M:160346112 DEBUG: Initialize - using alsa device hdmi
19:24:42 T:3052422976 M:160346112 DEBUG: CALSADirectSound::Initialize - packet size:2048, packet count:16, buffer size:8192
19:24:42 T:3052422976 M:160346112 WARNING: CALSADirectSound::CALSADirectSound - requested samplerate (44100) not supported by hardware, using 48000 instead
So it seems that 3 things are not happening here. XBMC is not resampling, ALSA is not resampling and the HW itself is not resampling. Ugh.
I looked around and found docs on how to create a virtual device and use libsamplerate to resample the audio, but for reasons beyond logic I just didn't really like that solution. I decided instead to slave the hdmi (codec#3) off the realtek (codec#0)
I added the following to my /etc/asound.conf
Code:
pcm.!default {
type plug
slave {
pcm "hdmi"
}
}In "Settings > Audio hardware" I have chosen the following options:
Audio output: Analog
Audio output device: default
Downmix multichannel to stereo: enabled
If people have the following setup:
PC[HDMI] --> RECEIVER[HDMI] --> TV
then I assume the following would work:
Audio output: Digital
AC3 passthrough: Enabled
DTS passthrough: Enabled
Audio output device: default (remember, it's slaved)
Passthrough output device: hdmi
Downmix multichannel: Disabled
What I've found is that if I do not enable the downmix multichannel option, when I play movies with 5.1 soundtracks, I get no audio over HDMI. This is because when I choose "default" as the device, XBMC will choose "surround51" as the output device for multichannel soundtracks. This could probably be fixed by modifying surround51 and slaving hdmi off that too, but since I am going from PC --> TV, I have no need for multichannel audio anyway.
Another benefit (if you can call it that) is that you will be able to hear the menu/navigation sounds again.
My tests have confirmed that 44.1kHz music files are now being properly resampled instead of played in helium mode, and movies are still playing properly. The only thing I'm not sure is, what is actually doing the resampling? My *hope* is that it is the audio hardware, but for all I know it could be ALSA. Either way, it works and navigation sounds are back!
Edit: adding a pcm.!surround51 section to /etc/asound.conf and slaving hdmi also works, however some additional work needs to be done to get alsa to remap/downmix the channels to 2 speakers. easier to just have xbmc do it, though it could be useful if you have a receiver setup and need/can support multichannel pcm (i don't think any receivers support that though, do they?)
- bobo1on1 - 2009-03-19
ashlar Wrote:Are you aware that there is a Smoothvideo branch being worked on? It's based on the same principles of the Reclock sound renderer under Windows.Spdif is not the problem, the problem is you can't resample and have ac3/dts passthrough.
It resamples sound so as to keep everything in synch, correcting the minor differences that happen among the system clock, graphic card clock, soundcard clock, etc.
Also, it's capable of slowing down 25fps accelerated material back to its original 24fps (this is a problem in PAL territories).
It can perform the first function with SPDIF if the refresh rate it's really close to optimal, otherwise it has to drop packets and that can be bad. It can't perform the second function with SPDIF, as packets dropped would be unacceptable.
Read here http://forum.xbmc.org/showthread.php?tid=46091
Pcm over spdif can still be resampled, it just limits you to 2 channel sound.