+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93)
+--- Thread: Testing audio engine ActiveAE (/showthread.php?tid=170338)
RE: Testing audio engine ActiveAE - fritsch - 2014-04-30
The 48 khz is quite clear - as you most likely have DMIX enabled in your system - so you only see the dmix rate here. Please configure your system correctly, e.g. disable dmix and you see all sample rates.
Edit: Wait this is OpenELEC - they should not have dmix at all, please also provide aplay -L (large L)
Edit2: When it is in the log you should be able to choose it. To be really sure, use Confluence Skin, perhaps switch to "Advanced" View, but Audio device selection should be possible.
RE: Testing audio engine ActiveAE - MGA1500 - 2014-04-30
(2014-04-30, 21:53)fritsch Wrote: The 48 khz is quite clear - as you most likely have DMIX enabled in your system - so you only see the dmix rate here. Please configure your system correctly, e.g. disable dmix and you see all sample rates.
Edit: Wait this is OpenELEC - they should not have dmix at all, please also provide aplay -L (large L)
Edit2: When it is in the log you should be able to choose it. To be really sure, use Confluence Skin, perhaps switch to "Advanced" View, but Audio device selection should be possible.
Ha! So the small expert of the logging told you enough ;-) So compared to Frodo there is kind of a filter applied when selecting audio devices depending on what output configuration/DMIX/passthrough settings are selected?
The only thing I changed now is that I disabled passthrough but the device does show. Does this makes sense to you or did the enabling of debug mode make a difference? Just making sure that this is designed behaviour ;-)
Thx!
RE: Testing audio engine ActiveAE - fritsch - 2014-04-30
Nope - you have two selections
a) PCM device, which lists all devices
b) Passthrough device, here you only see SPDIF and HDMI devices - as PCM devices are not able to passthrough. If you want everything out via the ANALOG out, yes you have to disable passthrough.
RE: Testing audio engine ActiveAE - hugo57 - 2014-05-02
Hi Guys,
Seeing some new "aefix"-es in Github I thought it is time again to install the latest nightly (20140502) and I want to tell you: IT SOUNDS REALLY FANTASTIC. The stereo image has become even better, much deeper. On proper recordings you can really hear if an instrument is playing in the foreground or more in the background. I had to force myself to get up and stop listening one piece after the other...
It is absolutely amazing what you have achieved with this project. I really mean it!
Huge congrats and a big thank you!
RE: Testing audio engine ActiveAE - FernetMenta - 2014-05-02
I am glad that you have fun. Thanks very much for the nice feedback!
RE: Testing audio engine ActiveAE - MGA1500 - 2014-05-06
(2014-04-30, 21:53)fritsch Wrote: The 48 khz is quite clear - as you most likely have DMIX enabled in your system - so you only see the dmix rate here. Please configure your system correctly, e.g. disable dmix and you see all sample rates.
Edit: Wait this is OpenELEC - they should not have dmix at all, please also provide aplay -L (large L)
Edit2: When it is in the log you should be able to choose it. To be really sure, use Confluence Skin, perhaps switch to "Advanced" View, but Audio device selection should be possible.
Hi Fritsch,
I have observed a non-detection again and went back to the forum this afternoon. I saw your edits. See below the aplay -L output:
Code:
login as: root
[email protected]'s password:
##############################################
# OpenELEC - The living room PC for everyone #
# ...... visit http://www.openelec.tv ...... #
##############################################
OpenELEC (official) Version: 4.0.0
OpenELEC:~ # aplay -L
null
Discard all samples (playback) or generate zero samples (capture)
hdmi:CARD=HDMI,DEV=0
HDA Intel HDMI, HDMI 0
HDMI Audio Output
hdmi:CARD=HDMI,DEV=1
HDA Intel HDMI, HDMI 1
HDMI Audio Output
hdmi:CARD=HDMI,DEV=2
HDA Intel HDMI, HDMI 2
HDMI Audio Output
default:CARD=PCH
HDA Intel PCH, ALC887-VD Analog
Default Audio Device
sysdefault:CARD=PCH
HDA Intel PCH, ALC887-VD Analog
Default Audio Device
front:CARD=PCH,DEV=0
HDA Intel PCH, ALC887-VD Analog
Front speakers
surround40:CARD=PCH,DEV=0
HDA Intel PCH, ALC887-VD Analog
4.0 Surround output to Front and Rear speakers
surround41:CARD=PCH,DEV=0
HDA Intel PCH, ALC887-VD Analog
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=PCH,DEV=0
HDA Intel PCH, ALC887-VD Analog
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=PCH,DEV=0
HDA Intel PCH, ALC887-VD Analog
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=PCH,DEV=0
HDA Intel PCH, ALC887-VD Analog
7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
default:CARD=SPHEREAUDIOOUTP
SPHERE_AUDIO_OUTPUTS, USB Audio
Default Audio Device
sysdefault:CARD=SPHEREAUDIOOUTP
SPHERE_AUDIO_OUTPUTS, USB Audio
Default Audio Device
front:CARD=SPHEREAUDIOOUTP,DEV=0
SPHERE_AUDIO_OUTPUTS, USB Audio
Front speakers
surround40:CARD=SPHEREAUDIOOUTP,DEV=0
SPHERE_AUDIO_OUTPUTS, USB Audio
4.0 Surround output to Front and Rear speakers
surround41:CARD=SPHEREAUDIOOUTP,DEV=0
SPHERE_AUDIO_OUTPUTS, USB Audio
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=SPHEREAUDIOOUTP,DEV=0
SPHERE_AUDIO_OUTPUTS, USB Audio
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=SPHEREAUDIOOUTP,DEV=0
SPHERE_AUDIO_OUTPUTS, USB Audio
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=SPHEREAUDIOOUTP,DEV=0
SPHERE_AUDIO_OUTPUTS, USB Audio
7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
iec958:CARD=SPHEREAUDIOOUTP,DEV=0
SPHERE_AUDIO_OUTPUTS, USB Audio
IEC958 (S/PDIF) Digital Audio Output
OpenELEC:~ #Somehow it looks like the device is enumerated as only supporting 48kHz which influences the visibility of the device when selecting it in the setings menu. Changing the skin as you suggested did not make a difference.
Additionally I observed when you play around with fixed/best match/optimised sample rate setting, but end with selecting best match, the dac will not change sampling frequency anymore. Only a reboot of the system lets the DAC follow the sample frequency of the track again.
I have a DAC code running that allows me to constantly display all kinds of USB parameters, like feedback rate per USB microframe so I could double check the sample frequency it was running on. I have a default playlist with all sample frequencies (44100,48000,88200,96000,176400,192000) that I test after every reboot.
If you need XBMC loggin information please let me know.
Regards, MGA
PS. Indeed only using Openelec platform and did an update to the latest version tonight...
RE: Testing audio engine ActiveAE - fritsch - 2014-05-06
Do you say: it works sometimes and sometimes not? ALSA has not hotplug, so if you power on that device too late, it won't be listed.
RE: Testing audio engine ActiveAE - MGA1500 - 2014-05-06
(2014-05-06, 21:01)fritsch Wrote: Do you say: it works sometimes and sometimes not? ALSA has not hotplug, so if you power on that device too late, it won't be listed.
Hi Fritsch,
I thought of that as well; I disconnected the DAC from the integrated setup and now have an identical DAC connected that is always powered on. Depending on the XBMC Audio Settings it does show up in the list or not after reboot. I am continuing with changin settings and rebooting until I know what influences the detection.
Can it be that the sampling frequency setting (the one that shows up when selecting FIXED) is stored somewhere and is read during startup which influences visibility in XBMC (icw the 48kHz that shows in the XBMC log during enumeration)?
While awaiting your reply I will continue testing different permutations ;-)
Regards
RE: Testing audio engine ActiveAE - fritsch - 2014-05-06
Try to compare dmesg output of "working" and non working boots. That sounds more like a kernel / alsa issue. You can also try to restart only xbmc with the systemd script (systemctl xbmc stop and systemctl xbmc start).
RE: Testing audio engine ActiveAE - MGA1500 - 2014-05-08
(2014-05-06, 21:21)fritsch Wrote: Try to compare dmesg output of "working" and non working boots. That sounds more like a kernel / alsa issue. You can also try to restart only xbmc with the systemd script (systemctl xbmc stop and systemctl xbmc start).
Hi Fritsch,
having done quite some debugging I can tell you that I have not found differences in dmesg logging between working and non-working setups, besides slight differences in the order in which non-audio related (in my view at least...) services are started. The same also goes for the aplay -l and -L outputs. What DOES make a difference however -and might be a hint towards the problem- is the openelec option (in the openelec program addon) of 'wait for network to be ready'.
If this is enabled, the output is listed in XBMC, with the option disabled it does NOT list in XBMC!
XBMC logging output in both cases does list my audio output. Is this strange or what?
In the meantime I will continue to try and find differences between the XBMC logging files between working and non-working setups but maybe the observation above makes you think in a certain direction?
I also reversed to Frodo temprarily but the effect does not show there; 'waiting for network to be ready' does not make a difference and the card is always detected.
As I am now able to reproduce the problem I feel we are halfway a solution ;-)
Regards,
RE: Testing audio engine ActiveAE - MGA1500 - 2014-05-14
(2014-05-08, 10:52)MGA1500 Wrote:(2014-05-06, 21:21)fritsch Wrote: Try to compare dmesg output of "working" and non working boots. That sounds more like a kernel / alsa issue. You can also try to restart only xbmc with the systemd script (systemctl xbmc stop and systemctl xbmc start).
Hi Fritsch,
having done quite some debugging I can tell you that I have not found differences in dmesg logging between working and non-working setups, besides slight differences in the order in which non-audio related (in my view at least...) services are started. The same also goes for the aplay -l and -L outputs. What DOES make a difference however -and might be a hint towards the problem- is the openelec option (in the openelec program addon) of 'wait for network to be ready'.
If this is enabled, the output is listed in XBMC, with the option disabled it does NOT list in XBMC!
XBMC logging output in both cases does list my audio output. Is this strange or what?
In the meantime I will continue to try and find differences between the XBMC logging files between working and non-working setups but maybe the observation above makes you think in a certain direction?
I also reversed to Frodo temprarily but the effect does not show there; 'waiting for network to be ready' does not make a difference and the card is always detected.
As I am now able to reproduce the problem I feel we are halfway a solution ;-)
Regards,
Hi Fritsch,
I have not been able to find a meaningful differnce in the logging as yet. In the meantime I verified that our USBDAC has booted and is succesfully enumerated before the Linux kernel is finished booting. Still the behaviour is consistent ie. when 'wait for network before starting XBMC' in the Openelec settings is disabled the USBDAC is not detected and vice versa.
Diving in the code of the new Audio Engine I see that volume control is dependent of whether the sink has the capability of volume control or not. Am I correct that in case ALSA (is default sink, please correct me if I am wrong) is the sink that the audio engine will use the ALSA ctl.xxxx device for volume control?
In case of most USBDACs there is no hardware volume control. Will ALSA softvol be used instead? I tried finding out by observing alsamixer, but I do not see any volume setting change if I adjust the same in XBMC.
For my application I'd like to add hardware volume control, but want to make sure that the audio engine will indeed use it before developing the code. Can I add a dummy volume control and add it to the USBDAC to test if it works or can you indicate a better, XBMC-structure-compatible volume control?
In the meantime I will find a good file compare tool to detect the difference in the first-mentioned logfiles to finf out why the USBDAC is not detected...
Regards, MGA
RE: Testing audio engine ActiveAE - fritsch - 2014-05-14
We always use softvolume for the alsa sink.
RE: Testing audio engine ActiveAE - MGA1500 - 2014-05-15
(2014-05-14, 20:45)fritsch Wrote: We always use softvolume for the alsa sink.
This is since Gotham I presume? Or was is always there? Also in the AE code I see internal volume control; is that only used when the sink does not support volume control or are there other applications? I'd like to disable volume control so that our USBDAC always get the 0dB samples and have the volume control implemented all the way to JUST before the amplifier. This means either disabling the internal volume control by commenting out stuff (definitely a non-preferred, non-reusable way!) in the XBMC code or doing it in a proper way by replacing the softvol with a control that does not affect the samples but sends it to our USB endpoint. Alternatively, softvol is replaced by a dummy volume control and through the OnVolumeChanged() function in XBMC this volume setting is sent to our application.
Before deciding on the way to implement, may I ask you for your opinion as to which way you would prefer to keep XBMC as tidy and structured as it currently is? Ofcourse the implementation should be usefull to others as well, so I want to implement it as generic as possible.
Thx!
RE: Testing audio engine ActiveAE - fritsch - 2014-05-15
When the volume slider is at the max, nothing will be done to the stream.
RE: Testing audio engine ActiveAE - MGA1500 - 2014-05-15
(2014-05-15, 10:58)fritsch Wrote: When the volume slider is at the max, nothing will be done to the stream.
I guessed so; to make sure you understand what I am looking for please let me explain the thing I am after: while still using keyboard controls, OSD, json remotes etc with XBMC fully functional; the volume that the DAC reveives still needs to be 0dB while the volume that XBMC reports (through OSD etc) is send to our own application that controls the DACs further down the stream.
This way we keep full resolution through all processing and only (literally) a few centimeters before the speaker units apply volume control.
Initially I wanted to expand the USBDAC sourcecode with hardware volume control and send it over UART (part of USBDAC) to our system , but since I have looked at the AE code (using sink, detecting if sink supports colume control etc) I'd like to use the ALSA configuration options to tell AE that volume control is available, disable the volume controls to be processed by softvol, and introduce a dummy volume control that does not do anything with the volume.
Thas way, XBMC will think it is using a volume control while in reality nothing happens to the gain level.
Am I thinking too complex here? These are my first steps into ALSA so bear with me; -)
Thx!