Re: [pulseaudio-discuss] [PATCH 1/4] A2DP api with multi-codec support

2018-12-15 Thread Huang-Huang Bao

On 12/16/18 5:48 AM, Pali Rohár wrote:
> On Thursday 13 December 2018 19:43:36 EHfive wrote:
>> diff --git a/src/modules/bluetooth/a2dp/a2dp-api.h 
>> b/src/modules/bluetooth/a2dp/a2dp-api.h
>> new file mode 100644
>> index 0..b357555d0
>> --- /dev/null
>> +++ b/src/modules/bluetooth/a2dp/a2dp-api.h
>> @@ -0,0 +1,170 @@
>> +#ifndef fooa2dpcodecapifoo
>> +#define fooa2dpcodecapifoo
>> +
>> +#ifdef HAVE_CONFIG_H
>> +
>> +#include 
>> +
>> +#endif
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "a2dp-codecs.h"
>> +#include "rtp.h"
>> +
>> +typedef struct pa_a2dp_codec pa_a2dp_codec_t;
>> +typedef struct pa_a2dp_config pa_a2dp_config_t;
>> +
>> +extern const pa_a2dp_codec_t pa_a2dp_sbc;
>> +
>> +
>> +/* Run from .encode */
>> +
>> +typedef void (*pa_a2dp_source_read_cb_t)(const void **read_buf, size_t 
>> read_buf_size, void *data);
>> +
>> +typedef void (*pa_a2dp_source_read_buf_free_cb_t)(const void **read_buf, 
>> void *data);
>> +
>> +
>> +// Larger index stands for higher priority by default
>> +typedef enum pa_a2dp_codec_index {
>> +PA_A2DP_SINK_MIN,
>> +PA_A2DP_SINK_SBC,
>> +PA_A2DP_SINK_MAX,
>> +PA_A2DP_SOURCE_MIN = PA_A2DP_SINK_MAX,
>> +PA_A2DP_SOURCE_SBC,
>> +PA_A2DP_SOURCE_MAX,
>> +PA_A2DP_CODEC_INDEX_UNAVAILABLE
>> +} pa_a2dp_codec_index_t;
> This priority enum seems to be strange. One enum mixes both sink and
> sources priorities? And why sink max has same value as source min?

Because there are some functions in a2dp-codec needs it, one enum let
functions more concise.

"PA_A2DP_SOURCE_MIN = PA_A2DP_SINK_MAX" is no sense.

>> +typedef struct pa_a2dp_sink {
>> +int priority;
>> +
>> +/* Load decoder if it's not loaded; Return true if it's loaded */
>> +bool (*decoder_load)();
> It is really needed? Cannot be decoder library dynamically linked into
> pulseaudio bluez module, and therefore by definition always loaded?

If 's encoder/decoder not loaded, the load function
should return false, then "pa_a2dp_init()" would not add that codec
index to indices lists.

In this patch, all codecs libraries dynamically linked so the
"decoder_load()" always return true;

Except ffmpeg, which require a motion for loading aptX(HD) encoder/decoder.

It just support dynamic loading .

> Support for dlopening decoders at runtime just cause problems. Some
> users would have installed needed libraries and it work without
> problems. Some not and it will not work... And all users have same
> pulseaudio version and compiled with same flags..
>
>> +/* Memory management is pa_a2dp_sink's work */
>> +bool (*init)(void **codec_data);
>> +
>> +/* Optional. Update user configurations
>> + * Note: not transport 'configuration' or 'capabilities' */
>> +int (*update_user_config)(pa_proplist *user_config, void **codec_data);
>> +
>> +void (*config_transport)(pa_sample_spec default_sample_spec, const void 
>> *configuration, size_t configuration_size,
>> + pa_sample_spec *sample_spec, void 
>> **codec_data);
>> +
>> +void (*get_block_size)(size_t read_link_mtu, size_t *read_block_size, 
>> void **codec_data);
>> +
>> +void (*setup_stream)(void **codec_data);
>> +
>> +size_t
>> +(*decode)(const void *read_buf, size_t read_buf_size, void *write_buf, 
>> size_t write_buf_size, size_t *decoded,
>> +  uint32_t *timestamp, void **codec_data);
>> +
>> +void (*free)(void **codec_data);
>> +} pa_a2dp_sink_t;
>> +
>> +
>> +typedef struct pa_a2dp_source {
>> +int priority;
>> +
>> +/* Load encoder if it's not loaded; Return true if it's loaded */
>> +bool (*encoder_load)();
>> +
>> +/* Memory management is pa_a2dp_source's work */
>> +bool (*init)(pa_a2dp_source_read_cb_t read_cb, 
>> pa_a2dp_source_read_buf_free_cb_t free_cb, void **codec_data);
>> +
>> +/* Optional. Update user configurations
>> + * Note: not transport 'configuration' or 'capabilities' */
>> +int (*update_user_config)(pa_proplist *user_config, void **codec_data);
>> +
>> +void (*config_transport)(pa_sample_spec default_sample_spec, const void 
>> *configuration, size_t configuration_size,
>> + pa_sample_spec *sample_spec, void 
>> **codec_data);
>> +
>> +void (*get_block_size)(size_t write_link_mtu, size_t *write_block_size, 
>> void **codec_data);
>> +
>> +void (*setup_stream)(void **codec_data);
>> +
>> +/* The implement should pass read_cb_data to pa_a2dp_source_read_cb, 
>> pa_a2dp_source_read_buf_free_cb */
>> +size_t (*encode)(uint32_t timestamp, void *write_buf, size_t 
>> write_buf_size, size_t *encoded,
>> + void *read_cb_data, void **codec_data);
>> +
>> +/* Optional */
>> +void (*set_tx_length)(size_t len, void **codec_data);
>> +
>> +/* Optional */
>> +void (*decrease_quality)(void **codec_data);
>> +
>> +void (*free)(void **codec_data);
>> +} pa_a2dp_source_t;
>> +
>> +
>> +struct pa_a2dp_codec 

Re: [pulseaudio-discuss] [PATCH 1/4] A2DP api with multi-codec support

2018-12-15 Thread Pali Rohár
On Saturday 15 December 2018 23:15:14 Pasi Kärkkäinen wrote:
> On Fri, Dec 14, 2018 at 12:01:57PM +0100, Pali Rohár wrote:
> > > >
> > > > Therefore that priority list is not always enforced.
> > > 
> > > How do you know?
> > 
> > Because I wrote my own implementation of aptX and FastStream codec
> > support for pulseaudio. Also I played with bluez a lot. In summer I sent
> > those my patches to pulseaudio mailing list, including proposal for
> > pulseaudio codec API.
> > 
> > And there was discussion about it. Also bluez developer confirmed that
> > priority list is not applied when headset initialize connection.
> >
> 
> So what's needed to get the pulseaudio codec api supported in pulseaudio / 
> patches merged? 
> Are there still not-yet-implemented items related to the pulseaudio codec api 
> proposal?
> More reviews needed?
> 
> I understand this is not a simple change, just trying to understand the 
> current status.

One of the missing part is bluez API for selecting / switching A2DP
codec. Without it, it is not possible to implement stable selection of
A2DP codec in pulseaudio.

I sent remainder email about this problem to linux-bluetooth ML:
https://www.spinics.net/lists/linux-bluetooth/msg78127.html

This is reason why I paused my work from summer for bringing Modular
codec API into pulseaudio. As all future work will depends on how that
new bluez dbus API would look like. Otherwise I would have finished my
Modular codec API... https://patchwork.freedesktop.org/series/46058/

Luiz proposed, that bluez could device's MediaEndpoint1 with
SelectConfiguration for every supported codec by remote device and
pulseaudio then could choose which one want. See:
https://www.spinics.net/lists/linux-bluetooth/msg76413.html

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

-- 
Pali Rohár
pali.ro...@gmail.com


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


Re: [pulseaudio-discuss] [PATCH 1/4] A2DP api with multi-codec support

2018-12-15 Thread Pali Rohár
On Thursday 13 December 2018 19:43:36 EHfive wrote:
> diff --git a/src/modules/bluetooth/a2dp/a2dp-api.h 
> b/src/modules/bluetooth/a2dp/a2dp-api.h
> new file mode 100644
> index 0..b357555d0
> --- /dev/null
> +++ b/src/modules/bluetooth/a2dp/a2dp-api.h
> @@ -0,0 +1,170 @@
> +#ifndef fooa2dpcodecapifoo
> +#define fooa2dpcodecapifoo
> +
> +#ifdef HAVE_CONFIG_H
> +
> +#include 
> +
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "a2dp-codecs.h"
> +#include "rtp.h"
> +
> +typedef struct pa_a2dp_codec pa_a2dp_codec_t;
> +typedef struct pa_a2dp_config pa_a2dp_config_t;
> +
> +extern const pa_a2dp_codec_t pa_a2dp_sbc;
> +
> +
> +/* Run from .encode */
> +
> +typedef void (*pa_a2dp_source_read_cb_t)(const void **read_buf, size_t 
> read_buf_size, void *data);
> +
> +typedef void (*pa_a2dp_source_read_buf_free_cb_t)(const void **read_buf, 
> void *data);
> +
> +
> +// Larger index stands for higher priority by default
> +typedef enum pa_a2dp_codec_index {
> +PA_A2DP_SINK_MIN,
> +PA_A2DP_SINK_SBC,
> +PA_A2DP_SINK_MAX,
> +PA_A2DP_SOURCE_MIN = PA_A2DP_SINK_MAX,
> +PA_A2DP_SOURCE_SBC,
> +PA_A2DP_SOURCE_MAX,
> +PA_A2DP_CODEC_INDEX_UNAVAILABLE
> +} pa_a2dp_codec_index_t;

This priority enum seems to be strange. One enum mixes both sink and
sources priorities? And why sink max has same value as source min?

> +typedef struct pa_a2dp_sink {
> +int priority;
> +
> +/* Load decoder if it's not loaded; Return true if it's loaded */
> +bool (*decoder_load)();

It is really needed? Cannot be decoder library dynamically linked into
pulseaudio bluez module, and therefore by definition always loaded?

Support for dlopening decoders at runtime just cause problems. Some
users would have installed needed libraries and it work without
problems. Some not and it will not work... And all users have same
pulseaudio version and compiled with same flags..

> +/* Memory management is pa_a2dp_sink's work */
> +bool (*init)(void **codec_data);
> +
> +/* Optional. Update user configurations
> + * Note: not transport 'configuration' or 'capabilities' */
> +int (*update_user_config)(pa_proplist *user_config, void **codec_data);
> +
> +void (*config_transport)(pa_sample_spec default_sample_spec, const void 
> *configuration, size_t configuration_size,
> + pa_sample_spec *sample_spec, void **codec_data);
> +
> +void (*get_block_size)(size_t read_link_mtu, size_t *read_block_size, 
> void **codec_data);
> +
> +void (*setup_stream)(void **codec_data);
> +
> +size_t
> +(*decode)(const void *read_buf, size_t read_buf_size, void *write_buf, 
> size_t write_buf_size, size_t *decoded,
> +  uint32_t *timestamp, void **codec_data);
> +
> +void (*free)(void **codec_data);
> +} pa_a2dp_sink_t;
> +
> +
> +typedef struct pa_a2dp_source {
> +int priority;
> +
> +/* Load encoder if it's not loaded; Return true if it's loaded */
> +bool (*encoder_load)();
> +
> +/* Memory management is pa_a2dp_source's work */
> +bool (*init)(pa_a2dp_source_read_cb_t read_cb, 
> pa_a2dp_source_read_buf_free_cb_t free_cb, void **codec_data);
> +
> +/* Optional. Update user configurations
> + * Note: not transport 'configuration' or 'capabilities' */
> +int (*update_user_config)(pa_proplist *user_config, void **codec_data);
> +
> +void (*config_transport)(pa_sample_spec default_sample_spec, const void 
> *configuration, size_t configuration_size,
> + pa_sample_spec *sample_spec, void **codec_data);
> +
> +void (*get_block_size)(size_t write_link_mtu, size_t *write_block_size, 
> void **codec_data);
> +
> +void (*setup_stream)(void **codec_data);
> +
> +/* The implement should pass read_cb_data to pa_a2dp_source_read_cb, 
> pa_a2dp_source_read_buf_free_cb */
> +size_t (*encode)(uint32_t timestamp, void *write_buf, size_t 
> write_buf_size, size_t *encoded,
> + void *read_cb_data, void **codec_data);
> +
> +/* Optional */
> +void (*set_tx_length)(size_t len, void **codec_data);
> +
> +/* Optional */
> +void (*decrease_quality)(void **codec_data);
> +
> +void (*free)(void **codec_data);
> +} pa_a2dp_source_t;
> +
> +
> +struct pa_a2dp_codec {
> +const char *name;
> +uint8_t codec;
> +const a2dp_vendor_codec_t *vendor_codec;
> +pa_a2dp_sink_t *a2dp_sink;
> +pa_a2dp_source_t *a2dp_source;
> +
> +/* Memory management is pa_a2dp_codec's work */
> +size_t (*get_capabilities)(void **capabilities);
> +
> +void (*free_capabilities)(void **capabilities);
> +
> +size_t (*select_configuration)(const pa_sample_spec default_sample_spec, 
> const uint8_t *supported_capabilities,
> +   const size_t capabilities_size, void 
> **configuration);
> +
> +void (*free_configuration)(void **configuration);

You can simplify memory management if caller (instead of calle

Re: [pulseaudio-discuss] [PATCH 1/4] A2DP api with multi-codec support

2018-12-15 Thread Pasi Kärkkäinen
On Fri, Dec 14, 2018 at 12:01:57PM +0100, Pali Rohár wrote:
> > >
> > > Therefore that priority list is not always enforced.
> > 
> > How do you know?
> 
> Because I wrote my own implementation of aptX and FastStream codec
> support for pulseaudio. Also I played with bluez a lot. In summer I sent
> those my patches to pulseaudio mailing list, including proposal for
> pulseaudio codec API.
> 
> And there was discussion about it. Also bluez developer confirmed that
> priority list is not applied when headset initialize connection.
>

So what's needed to get the pulseaudio codec api supported in pulseaudio / 
patches merged? 
Are there still not-yet-implemented items related to the pulseaudio codec api 
proposal?
More reviews needed?

I understand this is not a simple change, just trying to understand the current 
status.


Thanks,

-- Pasi

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


Re: [pulseaudio-discuss] [PATCH 1/4] A2DP api with multi-codec support

2018-12-15 Thread Pasi Kärkkäinen
On Fri, Dec 14, 2018 at 06:48:05PM +0800, Huang-Huang Bao wrote:
> I don't want to debate too much about naming. In this state, we should pay 
> attention to codes function.
> 
> Broken codes and useless codes could be cleaned up after this patches set 
> applied.
>

The common practice in opensource projects is that review comments
need to be addressed *before* the patches can be merged.

The author of the patches might need to post multiple iterations 
of the patches before all the reviewers/maintainers are happy with the patches, 
and the patches can then be merged.


-- Pasi

> If someone want to add another codec,  he/she can just modify 
> "a2dp-codeces.h" or others.
> 
> 
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss


Re: [pulseaudio-discuss] [PATCH 3/4] Add A2DP aptX, aptX HD codecs support

2018-12-15 Thread Pasi Kärkkäinen
On Thu, Dec 13, 2018 at 08:53:05PM +0100, Pali Rohár wrote:
> On Thursday 13 December 2018 18:42:11 Pasi Kärkkäinen wrote:
> > On Thu, Dec 13, 2018 at 04:36:59PM +0100, Pali Rohár wrote:
> > > What is the purpose of adding aptX codec (non HD variant)? It is not
> > > better then default and mandatory SBC codec.
> > >
> > 
> > When using AptX codec one can be certain it's always 352 kbps bitrate.
> > with SBC you never know what you end up using..
> 
> This is just because of current implementation of SBC in pulseaudio. Why
> not rather invest time to properly support SBC at high quality or allow
> user to set quality / show user current quality? SBC is mandatory and
> supported by all devices, aptX only by some (plus codec is proprietary).
>

I agree that pulseaudio should be improved so that it's easy to verify
the currently in use active codec settings/profile/bitrate.

 
> Adding aptX codec just because SBC implementation in pulseaudio is not
> so "nice" is not a good argument.
>

There are lots of physical AptX receiver/transmitter devices out there,
and while they of course also support SBC, they're often marketed as 
"AptX" high quality devices, so users will want to use AptX codec with them.

When you have both the SBC and AptX codecs available you can actually
easily compare them against each other, and use whatever you prefer :)


-- Pasi

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


Re: [pulseaudio-discuss] [PATCH 3/4] Add A2DP aptX, aptX HD codecs support

2018-12-15 Thread Pali Rohár
On Friday 14 December 2018 00:16:24 Huang-Huang Bao wrote:
> 90 samples are only 90/44100 s = 2ms , which is ignorable.

Yes, this not a problem. Problem is that first 90 samples is just
"garbage" or rather initialization data for predictor.

And to prevent hearing such "garbage" when decoding stream, you need to
drop them. Put aptX stream into aptX decoder, but drop first 90 samples
of decoded output.

Hearing noise or any other disrupting sound also for just 2ms is not
something which you want to hear.

This also applies when resetting decoder, e.g. after aptX parity check
does not match.

In most cases, first 90 decoded samples should be just silence (at least
this is doing ffmpeg and android's proprietary encoders). But when you
start decoding not from beginning but from existing stream, then it is
a problem.

Decoding from the middle of stream happens when some A2DP packets are
lost and decoder needs to be reset and start decoding again.

-- 
Pali Rohár
pali.ro...@gmail.com


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


Re: [pulseaudio-discuss] front-panel headphones not working with Intel PCH and Realtek ALC892 [solved]

2018-12-15 Thread Peter F. Patel-Schneider
Well, if not really solved at least I patched the problem, which is not really
about pulseaudio at all.


The Realtek ALC892 has a pin group that is by default a second line-in but can
be switched to be an output pin.  So there are four inputs by default, two
mic-level inputs and two line-level inputs.

Desktop motherboards don't generally have two line-level inputs.  Instead they
may have one line-level input on the back-panel I/O.   What they also have is
an HD audio header that almost always ends up being connected to two 3.5mm
jacks on the case.  One of the jacks is for a microphone and one is for
headphones.

My motherboard attaches the front mic pin and the second line-in pin from the
chip to this header.  Windows knows enough (probably by means of a quirk for
the motherboard) to repurpose the second line-in as a headphone jack.
However, this is not done in Linux.

I found out much of this from
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/993162 which is about a
different motherboard but the same chip and the same pin attachment.  I don't
know whether it is worthwhile to have a quirk added for my (old) motherboard.

So what I did was to use hdajackretask to retask pin 0x1b to Headphone, and
install a boot override for this.  I think that a reboot is needed to have the
change take total effect.

peter


On 12/14/18 12:33 PM, Russell Treleaven wrote:
> take 2
> `aplay -l` for the playback devices and `arecord -l` for the capture devices.
> Sometimes disabling auto-mute at the alsa layer makes the headphone jack show 
> up.
> 
> 
> 
> On Fri, Dec 14, 2018 at 11:14 AM Russell Treleaven  > wrote:
> 
> First thing is to do is verify that alsa sees the card.
> `aplay -l` for playback devices and `aplay -L` for capture devices.
> If alsa doesn't see it pulseaudio won't see it.
> 
> On Fri, Dec 14, 2018 at 10:56 AM Peter F. Patel-Schneider
> mailto:pfpschnei...@gmail.com>> wrote:
> 
> Hi:
> 
> I have an Intel 7 Series desktop where the audio chip is a Realtek 
> ALC892.
> The audio setup is quite normal, with 7+1+mic on the rear and mic and
> headphones on the front.
> 
> However, pulseaudio doesn't show a headphone port for the card (HDA 
> Intel
> PCH), just front and rear mics, digital output, HDMI 0 and 1, output
> lineout
> (which I assume is the 7+1 on the back), and input linein.
> 
> I looked around and found a few related documents but nothing that
> appears to
> be about this particular problem.  Does anyone know what is wrong? 
> How can I
> fiddle with the description of the card?
> 
> Thanks,
> 
> peter
> 
> 
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@lists.freedesktop.org
> 
> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
> 
> 
> 
> -- 
> Sincerely,
> 
> Russell Treleaven
> sip:rtrelea...@sip.bunnykick.ca
> ;transport=tcp
> 
> 
> 
> -- 
> Sincerely,
> 
> Russell Treleaven
> sip:rtrelea...@sip.bunnykick.ca
> ;transport=tcp
> 
> 
> ___
> 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] [PATCH 1/4] change bool save_sink to char *preferred_sink

2018-12-15 Thread Hui Wang

On 2018/12/12 下午9:39, Tanu Kaskinen wrote:

Thanks for working on this! Sorry for slow review, I hope I'll be much
quicker to comment on subsequent iterations.

On Mon, 2018-11-05 at 09:47 +0800, Hui Wang wrote:

And don't move the stream in the module-stream-restore anymore,
And the preferred_sink is only set when user is calling the
move_to() and the module-stream-restore maintains the saving and
deleting of preferred_sink.

If the target of move_to() is default_sink, preferred_sink will be
cleared and the entry->device will be cleared too from database.

Can you split this so that the first patch only changes save_sink to
preferred_sink, without any changes in behaviour? That is, put the
"don't move the stream in the module-stream-restore" and "if the target
of move_to() is default_sink" logic into separate patches.

Also replace tabs with spaces.

OK, got it, will addressed all comments.

Signed-off-by: Hui Wang 

[...]

  }
  }
@@ -2176,9 +2190,10 @@ static int extension_cb(pa_native_protocol *p, pa_module 
*m, pa_native_connectio
  
  entry->muted = muted;

  entry->muted_valid = true;
-
-entry->device = pa_xstrdup(device);
-entry->device_valid = device && !!entry->device[0];
+   if (device && !pa_streq(device, m->core->default_sink->name) && 
!pa_streq(device, m->core->default_source->name)) {
+   entry->device = pa_xstrdup(device);
+   entry->device_valid = device && !!entry->device[0];
+   }

What's the goal here? The client tries to change an entry in the
stream-restore database, why should that change be ignored if the
current default sink happens to be the same as the new device? Maybe
you intended to set entry->device to NULL in this case. But I don't
think that's necessary either - if the client wants to unset the
device, it can just give NULL as the device name. I don't think you
need to change anything here.

By the way, m->core->default_sink can be NULL, so that would have to be
checked if this code was kept.


Actually I didn't change this part first, but I remember the stream bond 
did not work as expected, after changed as above, it worked as expected.


Supposing sink0 is hdmi, and is playing a music over sink0, sink1 is 
speaker,  after I unplugged the hdmi cable, the music is switched to 
speaker,  but music->preferred_sink is still sink0-hdmi, after I plug 
the hdmi cable again, the music should be switched back to sink0-hdmi.  
I remember after I unplugged the cable, a user-space app call 
extension_cb to set the music->preferred_sink to be sink1-speaker 
(default_sink), then the music can't be switched back to hdmi anymore.


I will test it again, if it is really not needed, I will drop these code.


Thanks,

Hui.


  
  if (entry->device_valid && !pa_namereg_is_valid_name(entry->device)) {

  entry_free(entry);



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