All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] audio & dbus
Date: Thu, 16 Nov 2006 17:03:16 +0100	[thread overview]
Message-ID: <1163692996.5169.67.camel@localhost> (raw)
In-Reply-To: <455C8857.9050008@xmission.com>

Hi Brad,

> > So what you need is some kind of capabilities command and then you can
> > use this to create instances for all devices. So my proposal would be
> > that we use org.bluez.Audio as a configuration interface (like Manager)
> > and then org.bluez.Headset to actually connect, disconnect etc.
> 
> Ok... whatever it takes so the Play method is not ambiguous. I was 
> preparing to do all kinds of acrobatics to figure out what was intended 
> when changing the volume without a device connected but with the manager 
> idea that won't be so complicated.
> 
> I have looked over Manager but I need to examine the code to get a 
> better feel for this.

you basically differentiate the various attached headsets via different
object paths on D-Bus. So every headset is its own object.

> > No. Use IncreaseVolume and DecreaseVolume.
> 
> I was looking over my notes and the HSP profile and couldn't see the 
> need for these. I left them out but do we need them? Do we treat mic 
> gain this way too?
> 
> I started using Gain below instead of Volume since it applies to both 
> speaker and mic.

I don't care. My point was that we don't use a direction parameter.

> >> 		void AddWiredVoice()
> >>
> >> 			Add wired audio output to the voice routing rule
> >>
> >> 		void RemoveWiredVoice()
> >>
> >> 			Remove wired audio output from the voice routing
> >> 			rule
> > 
> > Not needed at all. This is not our business and the PCM routing will be
> > a parameter to the daemon. No need to support PCM and HCI routing at the
> > same time.
> 
> hmm... this is actually for interacting with the builtin speaker. Johan 
> mentioned the scenario of custom ringing both the headset and the 
> speaker simultaneously and there are other scenarios we would need to 
> interact with builtin audio (for example, to get a mic input with 
> today's a2dp headsets you would use the built-in mic)

This will be up to ALSA or GStreamer. It is not the job of the audio
daemon to handle non-Bluetooth stuff.

> Headset hierarchy (experimental)
> ==============================
> 
> Service		org.bluez
> Interface	org.bluez.Headset
> 
> Methods		void Connect(string identifier)
> 
> 			Opens the control connection to an audio device.
> 			Will not open the audio channel until requested
> 			by the audio plugin or directly from the
> 			application.
> 
> 		void Disconnect(string identifier)
> 
> 			Stops audio if it was playing and closes the
> 			control connection to the audio device.
> 
> 		void Play(string identifier)
> 
> 			Opens the audio stream. Called from the audio
> 			plugin or from the application if audio is
> 			routed somewhere other than the daemon (eg
> 			through PCM, direct to the DSP).
> 
> 		void Stop(string identifier)
> 
> 		void Pause(string identifier)
> 
> 		void Resume(string identifier)
> 
> 		void SetTimeout(string identifier, uint32 timeout)
> 
> 			Set the idle Stop for the device.
> 
> 			Only applicable when audio is routed through the
> 			daemon. Stop the stream and emit a signal if
> 			timeout elapses without any audio being sent
> 			to the daemon from an application. A value of 0
> 			indicates no idle stop; this is the default.
> 
> 		uint32 GetTimeout(string identifier)
> 
> 		uint16 GetSpeakerGain(string identifier)
> 
> 		uint16 GetMicrophoneGain(string identifier)
> 
> 		void SetSpeakerGain(string identifier, uint16 gain)
> 
> 			Gain is 0..15
> 
> 		void SetMicrophoneGain(string identifier, uint16 gain)
> 
> 			Gain is 0..15
> 
> 		void AddWiredVoice()
> 
> 			Add wired audio output to the voice routing rule
> 
> 		void RemoveWiredVoice()
> 
> 			Remove wired audio output from the voice routing
> 			rule

As mentioned above. I don't see the need for these two.

> 		void RingHeadset()
> 
> 			Indicate a single RING to the connected headset.

No need to do this. This should be handled automatically via Play or
some other method.

> 		void PressHeadsetButton()
> 
> 			Indicate a button press to the connected audio
> 			gateway.

Unneeded. We are not in the role of a headset.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

  reply	other threads:[~2006-11-16 16:03 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-16  6:14 [Bluez-devel] audio & dbus Brad Midgley
2006-11-16 10:22 ` Marcel Holtmann
2006-11-16 15:48   ` Brad Midgley
2006-11-16 16:03     ` Marcel Holtmann [this message]
2006-11-16 16:17       ` Johan Hedberg
2006-11-16 16:45       ` Brad Midgley
2006-11-16 17:18         ` Marcel Holtmann
2006-11-17 19:35           ` Brad Midgley
2006-11-17 19:53             ` Brad Midgley
2006-11-16 19:19       ` Brad Midgley
2006-11-16 19:38     ` Fabien Chevalier
2006-11-16 20:45       ` Brad Midgley
2006-11-16 19:27   ` Fabien Chevalier
2006-11-16 20:36     ` Brad Midgley
2006-11-19 17:20       ` Fabien Chevalier
2006-11-20  1:27         ` Brad Midgley
2006-11-21 19:23           ` Fabien Chevalier
2006-11-21 21:02             ` Brad Midgley
2006-11-22 11:09               ` Fabien Chevalier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1163692996.5169.67.camel@localhost \
    --to=marcel@holtmann.org \
    --cc=bluez-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.