[pulseaudio-discuss] Alsamixertest
So over the previous weeks I've been working on a small script which tests whether the ALSA mixer lives up to PA's expectations. If you are familiar with dbmeasure or dbverify by Lennart Poettering, this application's purpose is very similar, but this one is hopefully easier to set up, more user friendly, and also tests that the names of the volume controls are correct. My hope is that this will aid as a debugging tool for all these everything below 20% of my speaker is muted, and then 21% blows my speakers bugs. To use the tool, you'll need some kind of loopback. You can e g use a loopback cable and connect that between line in and line out, or test your laptop's internal speakers with your laptop's internal mic (just stop humming when you do so :-) ). Just set up the recording levels appropriately. Alsamixertest is available for Ubuntu Lucid and Ubuntu Maverick from these PPAs: Lucid: https://launchpad.net/~diwic/+archive/ppa Maverick: https://launchpad.net/~diwic/+archive/maverick For other distributions, download the tarball: https://launchpad.net/~diwic/+archive/ppa/+files/alsamixertest_47.14.tar.gz Unpack and read the readme file for compilation and install instructions. When it is installed, run alsamixertest -r for a small tutorial and alsamixertest -h for command line options help. Looking forward to your comments about this new little tool! I think it should be considered beta quality at this point. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Alsamixertest
'Twas brillig, and David Henningsson at 27/09/10 09:53 did gyre and gimble: So over the previous weeks I've been working on a small script which tests whether the ALSA mixer lives up to PA's expectations. If you are familiar with dbmeasure or dbverify by Lennart Poettering, this application's purpose is very similar, but this one is hopefully easier to set up, more user friendly, and also tests that the names of the volume controls are correct. My hope is that this will aid as a debugging tool for all these everything below 20% of my speaker is muted, and then 21% blows my speakers bugs. To use the tool, you'll need some kind of loopback. You can e g use a loopback cable and connect that between line in and line out, or test your laptop's internal speakers with your laptop's internal mic (just stop humming when you do so :-) ). Just set up the recording levels appropriately. Alsamixertest is available for Ubuntu Lucid and Ubuntu Maverick from these PPAs: Lucid: https://launchpad.net/~diwic/+archive/ppa Maverick: https://launchpad.net/~diwic/+archive/maverick For other distributions, download the tarball: https://launchpad.net/~diwic/+archive/ppa/+files/alsamixertest_47.14.tar.gz Unpack and read the readme file for compilation and install instructions. When it is installed, run alsamixertest -r for a small tutorial and alsamixertest -h for command line options help. Looking forward to your comments about this new little tool! I think it should be considered beta quality at this point. Cool. Packaged up for Mandriva too now. What license do you use. Couldn't seem to find any reference to it... Not tried it yet but will try and take it for a spin soon. Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Alsamixertest
'Twas brillig, and Colin Guthrie at 27/09/10 10:34 did gyre and gimble: 'Twas brillig, and David Henningsson at 27/09/10 09:53 did gyre and gimble: So over the previous weeks I've been working on a small script which tests whether the ALSA mixer lives up to PA's expectations. If you are familiar with dbmeasure or dbverify by Lennart Poettering, this application's purpose is very similar, but this one is hopefully easier to set up, more user friendly, and also tests that the names of the volume controls are correct. My hope is that this will aid as a debugging tool for all these everything below 20% of my speaker is muted, and then 21% blows my speakers bugs. To use the tool, you'll need some kind of loopback. You can e g use a loopback cable and connect that between line in and line out, or test your laptop's internal speakers with your laptop's internal mic (just stop humming when you do so :-) ). Just set up the recording levels appropriately. Alsamixertest is available for Ubuntu Lucid and Ubuntu Maverick from these PPAs: Lucid: https://launchpad.net/~diwic/+archive/ppa Maverick: https://launchpad.net/~diwic/+archive/maverick For other distributions, download the tarball: https://launchpad.net/~diwic/+archive/ppa/+files/alsamixertest_47.14.tar.gz Unpack and read the readme file for compilation and install instructions. When it is installed, run alsamixertest -r for a small tutorial and alsamixertest -h for command line options help. Looking forward to your comments about this new little tool! I think it should be considered beta quality at this point. Cool. Packaged up for Mandriva too now. What license do you use. Couldn't seem to find any reference to it... Not tried it yet but will try and take it for a spin soon. OK, for reference here is my output: I don't actually have a specific headphones profile (no separate mixer for headphones) but the results are more or less the same with and without the -p argument (the only thing different appears to be the range of the PCM tests). Ultimately the results seem to indicate that Master is OK, but out by a bit, but PCM is all kinds of broken. FWIW, the testing for -18.0, expected -21.04 measure -20.03dB is all a little confusing. When testing for -18.0, why is 021.04 expected? Perhaps some more explanation would be nice as to why the expected values differ from the test value. Anyway the output: [co...@jimmy pulse]$ alsamixertest -p analog-output-headphones INFO:root:Running initial test signal. INFO:root:Testing that Master actually mutes the signal INFO:root:Running test for mixer Master, level -3.00dB INFO:root:Running test for mixer Master, level -4.50dB INFO:root:Running test for mixer Master, level -6.00dB INFO:root:Running test for mixer Master, level -9.00dB INFO:root:Running test for mixer Master, level -10.50dB INFO:root:Running test for mixer Master, level -12.00dB INFO:root:Running test for mixer Master, level -15.00dB INFO:root:Running test for mixer Master, level -16.50dB INFO:root:Running test for mixer Master, level -18.00dB ERROR:root:Error 6: Mixer Master has invalid dB data for dB=-18.0, expected -21.04dB but measured -20.03dB. INFO:root:Running test for mixer Master, level -21.00dB ERROR:root:Error 6: Mixer Master has invalid dB data for dB=-21.0, expected -24.04dB but measured -22.72dB. INFO:root:Running test for mixer Master, level -22.50dB ERROR:root:Error 6: Mixer Master has invalid dB data for dB=-22.5, expected -25.54dB but measured -24.09dB. INFO:root:Running test for mixer Master, level -24.00dB ERROR:root:Error 6: Mixer Master has invalid dB data for dB=-24.0, expected -27.04dB but measured -25.40dB. INFO:root:Running test for mixer Master, level -27.00dB ERROR:root:Error 6: Mixer Master has invalid dB data for dB=-27.0, expected -30.04dB but measured -28.16dB. INFO:root:Running test for mixer Master, level -28.50dB ERROR:root:Error 6: Mixer Master has invalid dB data for dB=-28.5, expected -31.54dB but measured -29.30dB. INFO:root:Running test for mixer Master, level -30.00dB ERROR:root:Error 6: Mixer Master has invalid dB data for dB=-30.0, expected -33.04dB but measured -30.70dB. INFO:root:Running test for mixer Master, level -33.00dB ERROR:root:Error 6: Mixer Master has invalid dB data for dB=-33.0, expected -36.04dB but measured -33.43dB. INFO:root:Running test for mixer Master, level -34.50dB ERROR:root:Error 6: Mixer Master has invalid dB data for dB=-34.5, expected -37.54dB but measured -34.67dB. INFO:root:Running test for mixer PCM, level -2.00dB ERROR:root:Error 6: Mixer PCM has invalid dB data for dB=-2.0, expected -5.04dB but measured -3.05dB. INFO:root:Running test for mixer PCM, level -4.00dB ERROR:root:Error 6: Mixer PCM has invalid dB data for dB=-4.0, expected -7.04dB but measured -3.12dB. INFO:root:Running test for mixer PCM, level -6.00dB ERROR:root:Error 6: Mixer PCM has invalid dB data for dB=-6.0, expected -9.04dB but measured -3.11dB. INFO:root:Running test for
[pulseaudio-discuss] Some info on the RME Hammerfall DSP
I have had very limited success finding any information about what to do about the RME Hammerfall DSP Multiface II card in connection with Pulseaudio (running on Ubuntu Lucid 10.04). Basically, the best advice I had been able to find has been putting the lines load-module module-alsa-sink sink_name=dsp_out device=hw:DSP format=s32le channels=18 channel_map=left,right,aux0,aux1,aux2,aux3,aux4,aux5,aux6,aux7,aux8,aux9,aux10,aux11,aux12,aux13,aux14,aux15 tsched=0 load-module module-alsa-source source_name=dsp_in device=hw:DSP format=s32le channels=18 channel_map=left,right,aux0,aux1,aux2,aux3,aux4,aux5,aux6,aux7,aux8,aux9,aux10,aux11,aux12,aux13,aux14,aux15 tsched=0 into the default configuration. That works reasonably well, but one gets glitches most particularly when playing Flash audio. I just now figured out that removing the tsched=0 lines works fine as long as you run amixer -D hw:DSP cset numid=23 on before starting pulseaudio. amixer -D hw:DSP cget numid=23 now displays numid=23,iface=CARD,name='Precise Pointer' ; type=BOOLEAN,access=rw--,values=1 : values=on where the default is 'off'. Which does not appear to disturb Jack. But pulseaudio most certainly does not seem to like it, with tsched=1 suffering much worse than tsched=0. Setting this to 'On' makes pulseaudio work worse with tsched=0, and apparently have no problems with tsched=1. All this is rather crazy, and I have no idea where to report it such that a future version of Ubuntu will run out of the box. Is there any way I can get Pulseaudio to set this particular control when opening the hw:DSP device? Thanks -- David Kastrup ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Some info on the RME Hammerfall DSP
David Kastrup d...@gnu.org writes: [...] load-module module-alsa-sink sink_name=dsp_out device=hw:DSP format=s32le channels=18 channel_map=left,right,aux0,aux1,aux2,aux3,aux4,aux5,aux6,aux7,aux8,aux9,aux10,aux11,aux12,aux13,aux14,aux15 tsched=0 load-module module-alsa-source source_name=dsp_in device=hw:DSP format=s32le channels=18 channel_map=left,right,aux0,aux1,aux2,aux3,aux4,aux5,aux6,aux7,aux8,aux9,aux10,aux11,aux12,aux13,aux14,aux15 tsched=0 into the default configuration. That works reasonably well, but one gets glitches most particularly when playing Flash audio. I just now figured out that removing the tsched=0 lines works fine as long as you run amixer -D hw:DSP cset numid=23 on before starting pulseaudio. amixer -D hw:DSP cget numid=23 now displays numid=23,iface=CARD,name='Precise Pointer' ; type=BOOLEAN,access=rw--,values=1 : values=on where the default is 'off'. Which does not appear to disturb Jack. But pulseaudio most certainly does not seem to like it, with tsched=1 suffering much worse than tsched=0. Setting this to 'On' makes pulseaudio work worse with tsched=0, and apparently have no problems with tsched=1. Might likely be added as a PostScriptum to Trac ticket #764. Is there any way I can get Pulseaudio to set this particular control when opening the hw:DSP device? That I still want to know. -- David Kastrup ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Some info on the RME Hammerfall DSP
[I don't know whether this was moderated or whether you're a subscriber, so I added you.] On Mon, Sep 27, 2010 at 7:52 AM, David Kastrup d...@gnu.org wrote: amixer -D hw:DSP cget numid=23 now displays numid=23,iface=CARD,name='Precise Pointer' ; type=BOOLEAN,access=rw--,values=1 : values=on where the default is 'off'. Which does not appear to disturb Jack. But pulseaudio most certainly does not seem to like it, with tsched=1 suffering much worse than tsched=0. Setting this to 'On' makes pulseaudio work worse with tsched=0, and apparently have no problems with tsched=1. There are two places where this control can be set (i.e., the default changed), via alsactl's init db or in the driver itself. Because Maverick is in deep freeze, and because Lucid is in an even deeper freeze (having been released months ago), the best thing to do at this point is to file a bug using ubuntu-bug alsa-base so that the appropriate mixer information can be uploaded to Launchpad, and a patch can be generated for one of the above contexts. Personally, the former makes more sense and is less likely to cause regressions in the short term. The main thing to test then becomes confirming that jackd works correctly with that setting. After sufficient testing, the driver could be updated. All this is rather crazy, and I have no idea where to report it such that a future version of Ubuntu will run out of the box. There isn't an easy way to set everything up nicely for this particular card yet. The changes will touch alsa-lib and alsa-utils (or possibly alsa-driver, the latter depending on which route above is taken). Is there any way I can get Pulseaudio to set this particular control when opening the hw:DSP device? Sure, one can hack the mixer profile paths to set it, but that isn't the recommended way. It should be done via alsactl init. Best, -Dan ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Some info on the RME Hammerfall DSP
Daniel Chen seven.st...@gmail.com writes: [I don't know whether this was moderated or whether you're a subscriber, so I added you.] Reading through gmane. On Mon, Sep 27, 2010 at 7:52 AM, David Kastrup d...@gnu.org wrote: amixer -D hw:DSP cget numid=23 now displays numid=23,iface=CARD,name='Precise Pointer' ; type=BOOLEAN,access=rw--,values=1 : values=on where the default is 'off'. Which does not appear to disturb Jack. But pulseaudio most certainly does not seem to like it, with tsched=1 suffering much worse than tsched=0. Setting this to 'On' makes pulseaudio work worse with tsched=0, and apparently have no problems with tsched=1. There are two places where this control can be set (i.e., the default changed), via alsactl's init db or in the driver itself. Because Maverick is in deep freeze, and because Lucid is in an even deeper freeze (having been released months ago), the best thing to do at this point is to file a bug using ubuntu-bug alsa-base so that the appropriate mixer information can be uploaded to Launchpad, and a patch can be generated for one of the above contexts. Personally, the former makes more sense and is less likely to cause regressions in the short term. The main thing to test then becomes confirming that jackd works correctly with that setting. After sufficient testing, the driver could be updated. Well, I have no idea how to do this right. One obvious snag is that a setting like Precise Pointer is likely there for a reason. Why would anyone ask for imprecise pointers (the default) without there being an actual advantage? I have not yet found a rationale why this setting is there in the first place. I can't just believe there is a shoot yourself in the foot variable in a driver with a default of yes. I also have no idea about Maverick at all, and how it would cater for the Hammerfall with regard to Pulseaudio, defaults and so on. Would it be considered useful if I made the jump to Maverick prerelease right now? Who will then be doing the testing for a putative backport? -- David Kastrup ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Some info on the RME Hammerfall DSP
On Mon, Sep 27, 2010 at 8:32 AM, David Kastrup d...@gnu.org wrote: I also have no idea about Maverick at all, and how it would cater for the Hammerfall with regard to Pulseaudio, defaults and so on. The modifications that you made would still be necessary in Maverick. Would it be considered useful if I made the jump to Maverick prerelease right now? Who will then be doing the testing for a putative backport? My opinion is that it isn't absolutely necessary to move to Maverick (I dogfood the LTS releases). All the modifications that I suggested are possible in Lucid, too. It's probable that [Launchpad's] ~ubuntu-audio-dev will have a staging PulseAudio package (based on Maverick's) for Lucid soon. Best, -Dan ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Some info on the RME Hammerfall DSP
Daniel Chen seven.st...@gmail.com writes: On Mon, Sep 27, 2010 at 8:32 AM, David Kastrup d...@gnu.org wrote: I also have no idea about Maverick at all, and how it would cater for the Hammerfall with regard to Pulseaudio, defaults and so on. The modifications that you made would still be necessary in Maverick. Would it be considered useful if I made the jump to Maverick prerelease right now? Who will then be doing the testing for a putative backport? My opinion is that it isn't absolutely necessary to move to Maverick (I dogfood the LTS releases). All the modifications that I suggested are possible in Lucid, too. It's probable that [Launchpad's] ~ubuntu-audio-dev will have a staging PulseAudio package (based on Maverick's) for Lucid soon. The recipe can slightly be improved using amixer -D hw:DSP cset 'iface=CARD,name=Precise Pointer' On since that would be more symbolical and would likely do nothing to cards not in possession of such a control. I did some more experiments, and Flash Video continues to have skips. However, the previous artifacts sounded like wraparounds. The current ones apparently correspond to skipped frames. I have no idea why Flash would skip frames when there seems to be enough buffer of original content available, but maybe the codecs don't keep up. Right now I have a hard time convincing firefox/pulseaudio to try the builtin sound card for comparison. -- David Kastrup ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Some info on the RME Hammerfall DSP
Daniel Chen seven.st...@gmail.com writes: On Mon, Sep 27, 2010 at 8:32 AM, David Kastrup d...@gnu.org wrote: I also have no idea about Maverick at all, and how it would cater for the Hammerfall with regard to Pulseaudio, defaults and so on. The modifications that you made would still be necessary in Maverick. Would it be considered useful if I made the jump to Maverick prerelease right now? Who will then be doing the testing for a putative backport? My opinion is that it isn't absolutely necessary to move to Maverick (I dogfood the LTS releases). All the modifications that I suggested are possible in Lucid, too. It's probable that [Launchpad's] ~ubuntu-audio-dev will have a staging PulseAudio package (based on Maverick's) for Lucid soon. URL:https://bugs.launchpad.net/bugs/648992 -- David Kastrup ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] udev detection for 1 card with multiple devices
Hi all, I have this sound card with several hw devices attached, this is, it's only one card but I can configure/route all its numerous pcm/hw devices to have different sink/sources. For saying something I have hw:0,0 for playback/capture, on hw:0,1 only capture, hw:0,2 again for playback/capture, on hw:0,3 hdmi and so on. I've configured this card in the past using module-alsa-sink/source for each hw device and it works pretty fine. Recently I tried to use the udev module instead of module-alsa-sink/source but only the first hw device is recognized (hw:0,0) correctly for playback/capture... I'm wondering if this is the intended way (only first available device will be used) or it should also be capable of detecting the other devices or I need to do something else (like writing udev-rule?) but i'm no expert on udev stuff... FWIW I can see that all hw devices are correctly listed in /dev/snd directory... (I have /dev/snd/controlC0 and all of the /dev/snd/pcmC0D* entries) Any ideas or help will be appreciated! Thanks, Abraham ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] udev detection for 1 card with multiple devices
'Twas brillig, and abraham duenas at 27/09/10 18:12 did gyre and gimble: Hi all, I have this sound card with several hw devices attached, this is, it's only one card but I can configure/route all its numerous pcm/hw devices to have different sink/sources. For saying something I have hw:0,0 for playback/capture, on hw:0,1 only capture, hw:0,2 again for playback/capture, on hw:0,3 hdmi and so on. I've configured this card in the past using module-alsa-sink/source for each hw device and it works pretty fine. Recently I tried to use the udev module instead of module-alsa-sink/source but only the first hw device is recognized (hw:0,0) correctly for playback/capture... I'm wondering if this is the intended way (only first available device will be used) or it should also be capable of detecting the other devices or I need to do something else (like writing udev-rule?) but i'm no expert on udev stuff... FWIW I can see that all hw devices are correctly listed in /dev/snd directory... (I have /dev/snd/controlC0 and all of the /dev/snd/pcmC0D* entries) Any ideas or help will be appreciated! Yes this is possible and as you suspected it will involve writing a udev rule, but also writing a specific mixer profile too. If you look in your /usr/share/pulseaudio/alsa-mixer/ folder you'll see two folders. One is called paths and contains fairly generic config files to probe the various mixer elements in ALSA. What is likely more interesting is the profile-sets folder. It can contain custom configurations for more featureful and specialist cards such as yours. The task you have to complete is two fold: First of all you need to write your profile set itself. Take a look in the folder for examples. The files are quite liberally commented and I think this represents the only documentation (other than the source that parses them!). Once you have written your profile set for your hardware you have to tell PA to actually use it. This is where the udev rule comes in. Look at the file /lib/udev/rules.d/90-pulseaudio.rules. It contains a few lines to register the relevant profile set against your specific h/w via PCI or USB ids. Simply copy one of the three of four rules in there already and modify to suit. Once this is all working to your satisfaction, it would be great if you could submit your profile set and udev rule to us so we can include it in the standard install! If you have any questions just ask here and myself and the other folks here will do our best to help (tho' I personally do not have all that much experience with the mixer profiles specifically, I can generally poke about and find out more :)) Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
