>Also until the SCO setup is completed the SCO socket should >never be connected. So userspace can properly detect if SCO setup is in >progress and route it to the speaker with a proper audio policy. So I >think the emergency call argument is void. Way it works (most of opensource phone systems) - when phone is "connected" to HS/CarKit with no active Ccall ACL + RFCOMM (for AT commnds) is up, but SCO is down for power savings because there's no active audio. Physically audio is routed to HS all the time while HS ACL is up. When you enter call state phone will attempt to establish SCO over existing ACL with audio still routed to BT - this is when things get screwed up. several seconds later unsniff will fail, ACL will get messed up and disconnected and phone will switch to speaker. >So userspace can properly detect if SCO setup is in >progress and route it to the speaker with a proper audio policy. So during "normal" SCO setup (which can take up to 2.5 secs) you suggest to route audio back to speaker for 2.5 secs and then put it back to BT?:) Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
