Re: [pulseaudio-discuss] Revisiting raop2 patches

[Hajime Fujita]

Corin, Tanu, and Anton,

Thank you folks for your responses!

> On Oct 24, 2016, at 4:05 PM, Anton Lundin  wrote:
> 
> On 24 October, 2016 - Colin Leroy wrote:
> 
>> On 24 October 2016 at 20h58, Tanu Kaskinen wrote:
>> 
>> Hi, 
>> 
>>> It would be great to have more people reviewing patches, but I don't
>>> know how to acquire those people. I don't think the reviews have to
>>> necessarily be done by someone with a title of "maintainer", but on
>>> the other hand, giving much trust to drive-by contributors seems risky
>>> too...
>> 
>> Reviewing is hard when you don't have an extensive knowledge of the
>> codebase... I'd propose to do it, but I'd suck at it - "yeah, seems
>> fine to me" :D
>> 
> 
> I think we can file the raop2 code under a quite special category. It
> doesn't have a big inpact outside of the raop2 code, and those bits are
> quite trivial to review. I just read them my self and they looked ok to
> me =)

That sounds interesting. Not sure if it’s a good idea to essentially “skipping" 
reviews for non-raop2 patches, but it makes a lot of sense to focus on the 
patches that touch the core and other modules.

Actually as an author of the patches my expectation for the review was to make 
sure
a) we didn’t screw up when making changes to other parts of PA
b) naming conventions are acceptable
c) pulsecore API usages are correct

Any other concerns from maintainer’s point of view? I think this is also a good 
opportunity for me (and potentially others) to learn about the review process.

> On the other hand, the raop2 code itself is quit the opposite. It
> requires understanding of raop2 and pa.
> 
> Here comes the point: The current raop2 code is pretty much unusable.
> There are probably very few who have such old devices that they work
> with that code, and the changes only affects raop2 users.

This is a very valid point. I’d say this was already true three years ago when 
I started working on this project. And it was so disappointing to know that 
module-raop-sink didn’t work with most of the raop devices in the market 
despite its name. That’s the why I started working on this.

> I'd love to see the code merged, and even with the
> module-raop-discover module disabled by default. That way this change
> only affects users who really wants and uses this feature, and probably
> need this code to get their gear working.

FYI: in my understanding it’s already disabled by default.

> So my suggestion is to take a look at the non-raop2 patches so the
> maintainers are happy with those, and merge the lot.
> 
> 
> //Anton
> 
> 
> -- 
> Anton Lundin  +46702-161604
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Revisiting raop2 patches

[Anton Lundin]

On 24 October, 2016 - Colin Leroy wrote:

> On 24 October 2016 at 20h58, Tanu Kaskinen wrote:
> 
> Hi, 
> 
> > It would be great to have more people reviewing patches, but I don't
> > know how to acquire those people. I don't think the reviews have to
> > necessarily be done by someone with a title of "maintainer", but on
> > the other hand, giving much trust to drive-by contributors seems risky
> > too...
> 
> Reviewing is hard when you don't have an extensive knowledge of the
> codebase... I'd propose to do it, but I'd suck at it - "yeah, seems
> fine to me" :D
> 

I think we can file the raop2 code under a quite special category. It
doesn't have a big inpact outside of the raop2 code, and those bits are
quite trivial to review. I just read them my self and they looked ok to
me =)

On the other hand, the raop2 code itself is quit the opposite. It
requires understanding of raop2 and pa.

Here comes the point: The current raop2 code is pretty much unusable.
There are probably very few who have such old devices that they work
with that code, and the changes only affects raop2 users.

I'd love to see the code merged, and even with the
module-raop-discover module disabled by default. That way this change
only affects users who really wants and uses this feature, and probably
need this code to get their gear working.


So my suggestion is to take a look at the non-raop2 patches so the
maintainers are happy with those, and merge the lot.


//Anton


-- 
Anton Lundin+46702-161604
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Revisiting raop2 patches

[Colin Leroy]

On 24 October 2016 at 20h58, Tanu Kaskinen wrote:

Hi, 

> It would be great to have more people reviewing patches, but I don't
> know how to acquire those people. I don't think the reviews have to
> necessarily be done by someone with a title of "maintainer", but on
> the other hand, giving much trust to drive-by contributors seems risky
> too...

Reviewing is hard when you don't have an extensive knowledge of the
codebase... I'd propose to do it, but I'd suck at it - "yeah, seems
fine to me" :D

-- 
Colin


pgp7e38WNLNgR.pgp
Description: OpenPGP digital signature
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Revisiting raop2 patches

[Tanu Kaskinen]

On Sun, 2016-10-23 at 21:48 -0500, Hajime Fujita wrote:
> Hello,
> 
> This is to revisit the raop2 support patches for module-raop-sink, to
> extend the existing module-raop-sink so it supports much recent protocol
> (and thus much broader range of devices.)
> 
> General background can be seen here:
> https://lists.freedesktop.org/archives/pulseaudio-discuss/2016-January/025322.html
> 
> I truly understand that there's a huge shortage in manpower to review the
> patches, and that raop is not a high priority thing in the project.
> 
> However, there does exist many users who have been waiting for this feature
> to become available in PulseAudio, and actually some of them have been
> using this patch for daily basis. Having these patches upstreamed will
> surely benefit these users and make PulseAudio more competent software
> product.

Yes, it would be great to get this stuff merged. Thanks for not giving up!

> If there's anything I can help to make the review process easier and faster
> (other than rebasing the existing patches to the latest master), please do
> let me know.

The problem is that only me and Arun do reviews. I'm currently
concentrating on fixing the release blocker bugs, and Arun has been
busy with non-PA things lately (I hope that won't be a permanent
situation). After we get the release candidate out, I can start doing
reviews again, but I can't promise any particular timeline for
reviewing your patches. I can only promise not to forget about them.

It would be great to have more people reviewing patches, but I don't
know how to acquire those people. I don't think the reviews have to
necessarily be done by someone with a title of "maintainer", but on the
other hand, giving much trust to drive-by contributors seems risky
too...

If you (or anyone else reading this!) would be interested in becoming a
regular reviewer, I think we can make that happen.

-- 
Tanu
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Upgrading a pa script from Ubuntu 12.04 to 16.10

[Tanu Kaskinen]

On Sat, 2016-10-22 at 02:00 -0400, Joe wrote:
> Before I get into all the details of my script, etc., I would be very 
> happy to use someone else's utility that does what I want, if it already 
> exists. I want to click an icon and get results without having to 
> navigate through a bunch of GUI menus every time.
> 
> When it worked, I used this script many times a week, so I'd really like 
> to get it working again.
> 
> I cobbled together the attached script from posts on the Internet. It 
> worked fine in 12.04, but is completely broken in 16.04 because the 
> output of the commands it parses has changed, etc..

It would be helpful if you could describe in more detail what part of
the script isn't working as expected.

-- 
Tanu
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Digital input on Creative Sound Blaster X-FI HD

[Tanu Kaskinen]

On Fri, 2016-10-21 at 22:39 +0200, Oddbjørn Norstrand wrote:
> On Fri, Oct 21, 2016 at 04:35:46PM +0300, Tanu Kaskinen wrote:
> > This is pretty weird. It really looks like it should be working. Maybe
> > it's a mixer issue? That doesn't seem likely, but I don't have any
> > other ideas. So, start recording with parec, and while it's running,
> > save the output from "amixer -c2" and "pactl list". Then, stop parec,
> > set the card profile to "off" and start recording with ffmpeg. Save the
> > output from "amixer -c2" again. Then send the amixer and pactl output.
> > 
> > "pactl list" will be so big that it's best to either upload it
> > somewhere where I can download it from, or attach it as a compressed
> > file.
> 
> Thank you for trying to solve my problem. I have attached a compressed
> file with the outputs you requested. I hope it helps.
> 
> Since the last post I have also tried recording from analog input from
> the device and that works as expected using pulseaudio, but
> unfortunately at this time it is digital input I need.

There were no differences in the mixer state between parec and ffmpeg,
and the pactl output looked fine. I'm out of ideas.

-- 
Tanu
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Make pulseaudio the default alsa device

[Tanu Kaskinen]

On Fri, 2016-10-21 at 11:24 -0300, Felipe Sateler wrote:
> On 21 October 2016 at 10:22, Tanu Kaskinen  wrote:
> > Wouldn't per-user configuration be better suited for ~/.asoundrc? Now
> > you're assuming that if pulseaudio isn't available for whatever reason,
> > the user doesn't want to use pulseaudio. That's not always correct, but
> > it might be correct often enough that it makes sense for you to do that
> > instead of requiring users to modify ~/.asoundrc.
> 
> 
> Because pulseaudio defaults to autospawn, if the daemon can't be
> reached then for most users the current heuristic means either:
> 
> 1. Pulseaudio has been manually disabled via `autospawn = no`.
> 2. Pulseaudio is seriously malfunctioning and can't start.
> 
> In either case I don't think it makes much sense to set the alsa
> default device to pulseaudio.

When debugging pulseaudio problems, the first step is often disabling
autospawning so that pulseaudio can be started manually. If alsa
applications start to use the hardware directly in this situation,
that's not particularly helpful. (However, to be honest, I don't
remember actually experiencing this problem when debugging.)

If pulseaudio is seriously malfunctioning, it would be nice to get a
bug report, which is less likely if there's a fallback to skip
pulseaudio.

I think these are sensible reasons to not want an automatic fallback,
but I also acknowledge that it's entirely reasonable to prefer having
the fallback.

> > One alternative would be to create a program/script for
> > disabling/enabling pulseaudio (which is nowadays annoyingly
> > distribution specific, so a unifying script would be welcome even for
> > this reason alone), which would also (optionally) set up the default
> > device in ~/.asoundrc. That way there would be just one step for users
> > to toggle between pulseaudio and plain alsa.
> 
> 
> Does alsa support ~/.asoundrc.d or equivalent? Otherwise the script
> would get hairy very fast.

I would guess that there's no support for that. Such support could
probably be added reasonably easily, though.

> > However, alsa-plugins already has a file that sets
> > pulseaudio as the default device, and e.g. OpenEmbedded ships the
> > configuration in alsa-plugins-pulseaudio-conf, which is a binary
> > package generated from the alsa-plugins source.
> 
> 
> This is an interesting approach. Debian package pulseaudio could
> Recommends: alsa-plugins-pulseaudio-conf (this means install by
> default, but allow uninstalling). The only problem I see is how to
> disable per-user (via .asoundrc?). I have gotten requests to be able
> to disable per-application, because some specific apps malfunction
> with the pulse virtual device.

If you don't want to work on the script that enables/disables
pulseaudio, it seems to me that the best way forward would be to move
the configuration file that you're currently using from the pulseaudio
package to alsa-plugins-pulseaudio-conf, and submit it to alsa-plugins
upstream.

-- 
Tanu
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] RME Babyface Pro: How do I get pulseaudio to see output 3/4?

[Allan Wind]

I frequently switch between monitors (output 1/2) and headphones (output 3/4),
and doing so on hardware is a 2 or 3 step process, so I was hoping there is a
way to get pulseaudio to see output 3/4.

Here is what the relevant sink from pactl:

Sink #29
State: RUNNING
Name: 
alsa_output.usb-RME_Babyface_Pro__70793162__926E13156329DC8-00.analog-stereo
Description: Babyface Pro (70793162) Analog Stereo
Driver: module-alsa-card.c
Sample Specification: s24le 2ch 44100Hz
Channel Map: front-left,front-right
Owner Module: 48
Mute: no
Volume: front-left: 65807 / 100% / 0.11 dB,   front-right: 65807 / 100% 
/ 0.11 dB
balance 0.00
Base Volume: 65536 / 100% / 0.00 dB
Monitor Source: 
alsa_output.usb-RME_Babyface_Pro__70793162__926E13156329DC8-00.analog-stereo.monitor
Latency: 9333 usec, configured 8000 usec
Flags: HARDWARE DECIBEL_VOLUME LATENCY 
Properties:
alsa.resolution_bits = "24"
device.api = "alsa"
device.class = "sound"
alsa.class = "generic"
alsa.subclass = "generic-mix"
alsa.name = "USB Audio"
alsa.id = "USB Audio"
alsa.subdevice = "0"
alsa.subdevice_name = "subdevice #0"
alsa.device = "0"
alsa.card = "1"
alsa.card_name = "Babyface Pro (70793162)"
alsa.long_card_name = "RME Babyface Pro (70793162) at 
usb-:00:14.0-6, high speed"
alsa.driver_name = "snd_usb_audio"
device.bus_path = "pci-:00:14.0-usb-0:6:1.0"
sysfs.path = 
"/devices/pci:00/:00:14.0/usb1/1-6/1-6:1.0/sound/card1"
udev.id = "usb-RME_Babyface_Pro__70793162__926E13156329DC8-00"
device.bus = "usb"
device.vendor.id = "2a39"
device.vendor.name = "RME"
device.product.id = "3fb0"
device.product.name = "Babyface Pro (70793162)"
device.serial = "RME_Babyface_Pro__70793162__926E13156329DC8"
device.string = "front:1"
device.buffering.buffer_size = "529200"
device.buffering.fragment_size = "264600"
device.access_mode = "mmap+timer"
device.profile.name = "analog-stereo"
device.profile.description = "Analog Stereo"
device.description = "Babyface Pro (70793162) Analog Stereo"
alsa.mixer_name = "USB Mixer"
alsa.components = "USB2a39:3fb0"
module-udev-detect.discovered = "1"
device.icon_name = "audio-card-usb"
Ports:
analog-output: Analog Output (priority: 9900)
Active Port: analog-output
Formats:
pcm

I was able to see all 12 inputs in ardour.  `aplay -L` looks... well, not quite
right, this is multi-channel and not a surround card:

sysdefault:CARD=Pro70793162
Babyface Pro (70793162), USB Audio
Default Audio Device
front:CARD=Pro70793162,DEV=0
Babyface Pro (70793162), USB Audio
Front speakers
surround21:CARD=Pro70793162,DEV=0
Babyface Pro (70793162), USB Audio
2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=Pro70793162,DEV=0
Babyface Pro (70793162), USB Audio
4.0 Surround output to Front and Rear speakers
surround41:CARD=Pro70793162,DEV=0
Babyface Pro (70793162), USB Audio
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=Pro70793162,DEV=0
Babyface Pro (70793162), USB Audio
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=Pro70793162,DEV=0
Babyface Pro (70793162), USB Audio
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=Pro70793162,DEV=0
Babyface Pro (70793162), USB Audio
7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
iec958:CARD=Pro70793162,DEV=0
Babyface Pro (70793162), USB Audio
IEC958 (S/PDIF) Digital Audio Output
dmix:CARD=Pro70793162,DEV=0
Babyface Pro (70793162), USB Audio
Direct sample mixing device
dsnoop:CARD=Pro70793162,DEV=0
Babyface Pro (70793162), USB Audio
Direct sample snooping device
hw:CARD=Pro70793162,DEV=0
Babyface Pro (70793162), USB Audio
Direct hardware device without any conversions
plughw:CARD=Pro70793162,DEV=0
Babyface Pro (70793162), USB Audio
Hardware device with all software conversions

The authoritative nfo appears to be `cat /proc/asound/card1/stream0`:

 RME Babyface Pro (70793162) at usb-:00:14.0-6, high speed : USB Audio

Playback:
  Status: Running
Interface = 1
Altset = 1
Packet Size = 42
Momentary freq = 44118 Hz (0x5.83c9)
Feedback Format = 16.16
  Interface 1
Altset 1
Format: S24_3LE
Channels: 2
Endpoint: 3 OUT (ASYNC)
Rates: 

Re: [pulseaudio-discuss] Revisiting raop2 patches

[Colin Leroy]

Hello everybody, Hajime,

> I truly understand that there's a huge shortage in manpower to review
> the patches, and that raop is not a high priority thing in the
> project.

Thanks a lot, again, for your persistence with this patchset :) I still
use it daily and with no adverse effect rebased against PA 9.0 if I
remember correctly.

I would love to help getting this upstreamed but I don't really know
what more I could do?

Thanks,
-- 
Colin
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss