Mobile device audio notes

Abstract

System (1), comprising: a vehicle sound system connected to a mobile device (208) via a data connection (210) and an audio connection (206), and designed to request, via the data connection (210), that the mobile device (208) provide an audio cue (214) with the current volume level of the mobile device (208) via the audio connection (206) in response to a change in the volume level of the vehicle sound system, and to reproduce the audio cue (214) with the volume level of the vehicle sound system to indicate a loudness for sound played from the mobile device (208).

Description

[0001] This invention relates generally to providing audio cues by a device having a volume level to a system having a different volume level in order to inform a user about the overall loudness of the audio content being reproduced by the system, and to a corresponding method.

[0002] Various vehicle systems are known from the prior art. For example, US Patent 2008 / 0020807A1 discloses a method for calibrating a hands-free system in which a connection to a remote terminal is established via a mobile phone network. A test signal is transmitted between the hands-free system and the remote terminal and stored as a reference test signal. The received test signal is compared with the reference test signal to determine calibration parameters for the hands-free system.

[0003] US patent 2015 / 0127215A1 also describes a method for adjusting vehicle settings using an in-vehicle computer system based on input from a portable device. The vehicle settings can be automatically adjusted before any user input. The portable device can also be connected to the system via a network and transmit input directly.

[0004] Furthermore, WO 00 / 13 328 A1 discloses a sound-voice equipment for mobile phones in vehicles, which is mounted between the sound system and the power amplifier module with RCA connectors and uses the rear vehicle speakers for sound reproduction from the mobile phone.

[0005] Furthermore, DE 10 2013 016 095 A1 discloses a method for operating an audio playback device in a motor vehicle, which has at least two data inputs for audio content to be played back, wherein each data input is assigned at least one adjustment parameter for matching the playback of the same audio content from different data sources connected to the data inputs, wherein a first of the at least two data inputs is used to receive first audio content originating from a changing input data source, in particular an internet source, wherein the at least one adjustment parameter of the first data input is selected and set depending on the current input data source.

[0006] A vehicle data processing system (VCS) can be designed to play music or other audio from various sources. These sources can include, for example, radio, compact discs, and audio streaming via the internet. In some cases, the VCS may include an audio input that allows an external device to play audio through the VCS. Both the external device and the VCS may each include a volume control to allow the user to adjust the audio volume.

[0007] In a first illustrative embodiment, a system includes a vehicle system connected to a mobile device via a data link and an audio link, and designed to request, in response to a change in vehicle volume via the data link, that the mobile device provide an audio cue at device volume via the audio link, and to reproduce the audio cue at vehicle volume through the vehicle system to indicate a loudness for sound played from the mobile device.

[0008] In a second illustrative embodiment, a system includes a mobile device connected to a vehicle system via a data link and an audio link, and designed to receive a request via the data link, provide an audio cue via the audio link, and provide the audio cue at device volume via the audio link to cause the vehicle system to reproduce the audio cue at vehicle volume to indicate a loudness for sound played from the mobile device.

[0009] In a third illustrative embodiment, a computer-implemented method for a vehicle, in response to a change in vehicle volume for a vehicle system, includes requesting the mobile device to provide an audio cue via the audio link and reproducing the audio cue at vehicle volume through the vehicle system to indicate a loudness for sound played from the mobile device via the vehicle system.

[0010] The figures show: Fig. Figure 1 is an exemplary block topology of a vehicle infotainment system that implements a user-interactive vehicle-based computing system; Fig. 2 represents an exemplary system that includes a vehicle designed to play audio content from mobile devices via the vehicle's infotainment system; Fig. 3 presents an exemplary process for requesting audio cues regarding volume levels, to be provided by a mobile device, through the vehicle infotainment system; and Fig. Figure 4 presents an exemplary process for providing audio cues regarding volume levels by the mobile device, as requested by the vehicle infotainment system.

[0011] As required, detailed embodiments of the present invention are disclosed herein; however, it is understood that the disclosed embodiments are merely exemplary of the invention, which can be realized in various and alternative forms. The figures are not necessarily to scale; certain features may be exaggerated or minimized to show details of specific components. The specific structural and functional details disclosed herein are therefore not to be considered a limitation, but merely a representative basis for teaching those skilled in the art how to use the present invention in various ways.

[0012] Devices such as mobile phones and portable music players can be connected to a vehicle's audio input to deliver audio content through the vehicle's sound system. However, it can be difficult to determine in advance what the actual volume level of the audio content played through the vehicle will be. This is because there are two different volume levels that contribute to the overall sound level that will be delivered: (i) the volume level of the vehicle's sound system and (ii) the volume level of the connected device. Furthermore, it can also be difficult to communicate to the user the new volume level that will be heard when the vehicle's volume level is changed.

[0013] An enhanced vehicle sound system can be designed to use a data connection with a connected mobile device to request that the mobile device play an audio cue via an audio connection between the mobile device and the vehicle. The vehicle can then receive the audio cue from the device and reproduce it at the vehicle's volume level to indicate the overall volume of sound being played from the mobile device through the vehicle's system. The audio cue can be requested by the vehicle, for example, when the audio system volume is changed. Consequently, the system can be able to communicate the actual volume that will be heard when the user changes the vehicle's volume, without complex algorithms and calculations, by using the overall audio path from the mobile device through the vehicle's systems.

[0014] Although the disclosed examples are discussed in relation to a mobile device communicating with a vehicle audio system, it should be noted that the disclosed aspects are equally applicable to other audio sources with a volume level unknown to the sound-reproducing entity, such as an internet-based audio streaming service or in environments other than vehicles, such as lecture halls or outdoor presentations.

[0015] Fig. Figure 1 shows an exemplary block topology for a vehicle-integrated data processing system 1 (VCS 1) for a vehicle 31. An example of such a vehicle-integrated data processing system 1 is the SYNC system manufactured by THE FORD MOTOR COMPANY. A vehicle equipped with a vehicle-integrated data processing system may include an in-vehicle visual front-end interface 4. The user may also be able to interact with the interface if, for example, it is equipped with a touch-sensitive screen. In another exemplary embodiment, interaction is achieved through button presses, a speech dialogue system with automatic speech recognition, and speech synthesis.

[0016] At the in Fig. In the exemplary embodiment shown in Figure 1, a processor 3 controls at least part of the operation of the vehicle-based data processing system. The processor is located in the vehicle and allows onboard processing of instructions and routines. Furthermore, the processor is connected to non-persistent memory 5 and persistent memory 7. In this exemplary embodiment, the non-persistent memory is random access memory (RAM), and the persistent memory is a hard disk drive (HDD) or flash memory. In general, persistent (non-volatile) memory can include any type of memory that stores data when a computer or other device is turned off. This includes, but is not limited to, HDDs, CDs (compact disks), DVDs (digital versatile disks), magnetic tapes, solid-state drives, portable USB (universal serial bus) drives, and other suitable types of persistent memory.

[0017] The processor is also equipped with a number of different inputs that allow the user to connect to the processor. In this exemplary embodiment, a microphone 29, an auxiliary input 25 (for input 33), a USB input 23, a GPS input 24, a screen 4, which can be a touchscreen display, and a BLUETOOTH input 15 are provided. An input selector 51 is also provided to allow the user to switch between different inputs. Inputs to both the microphone and auxiliary inputs are converted from analog to digital by a converter 27 before being routed to the processor. Although not shown, numerous vehicle components and auxiliary components can communicate with the VCS using a vehicle network (such as, but not limited to, a CAN bus) to transmit data to and from the VCS (or components thereof).

[0018] Outputs from the system can include, but are not limited to, a visual display 4 and a speaker 13 or stereo output. The speaker is connected to an amplifier 11 and receives its signal from the processor 3 via a digital-to-analog converter 9. Outputs can also be made to a remote BLUETOOTH device, such as the PND 54, or a USB device, such as the vehicle navigation device 60, along the bidirectional data streams shown at 19 and 21, respectively.

[0019] In one exemplary embodiment, the system 1 uses the BLUETOOTH transmitter / receiver 15 to communicate 17 with a user's nomadic device 53 (e.g., mobile phone, smartphone, PDA, or any other device with connectivity to a remote wireless network). The nomadic device can then be used, for example, to communicate 59 with a network 61 outside the vehicle 31 by communicating 55 with a cell tower 57. In certain embodiments, the tower 57 can be a WiFi access point.

[0020] Exemplary communication between the nomadic facility and the BLUETOOTH transmitter / receiver is represented by signal 14.

[0021] Pairing a nomadic setup 53 and the BLUETOOTH transmitter / receiver 15 can be commanded by pressing a key 52 or similar input. Accordingly, the CPU is informed that the onboard BLUETOOTH transmitter / receiver is to be paired with a BLUETOOTH transmitter / receiver in a nomadic setup.

[0022] Data can be transmitted between the CPU 3 and the network 61, for example, using a data plan, data-over-voice, or DTMF tones associated with the nomadic device 53. Alternatively, it may be desirable to provide an onboard modem 63 with an antenna 18 to transmit data between the CPU 3 and the network 61 over the voice band 16. The nomadic device 53 can then be used, for example, to communicate with a network 61 outside the vehicle 31 by means of communication 55 with a cellular mast 57 59. In certain embodiments, the modem 63 can establish communication 20 with the mast 57 for communication with the network 61. As a non-limiting example, the modem 63 can be a USB cellular modem, and the communication 20 can be cellular communication.

[0023] In one exemplary embodiment, the processor is equipped with an operating system that includes an API for communicating with modem application software. The modem application software can access an embedded module or firmware on the Bluetooth transmitter / receiver to establish wireless communication with a remote Bluetooth transmitter / receiver (such as one found in a nomadic setup). Bluetooth is a subset of the IEEE 802 PAN (Personal Area Network) protocols. The IEEE 802 LAN (Local Area Network) protocols include Wi-Fi and have considerable cross-functionality with IEEE 802 PAN. Both are suitable for wireless communication within a vehicle. Other communication methods that can be used in this area include free-space optical communication (such as IrDA) and non-standard consumer IR protocols.

[0024] In another embodiment, the nomadic device 53 includes a modem for voice-band or broadband data communication. In the data-over-voice embodiment, a technique known as frequency-division multiplexing (FDM) can be implemented when the owner of the nomadic device can speak over the device while data is being transferred. At other times, when the owner is not using the device, the data transfer can use the entire bandwidth (in one example, 300 Hz to 3.4 kHz). Although FDM may be common and continues to be used for analog cellular communication between the vehicle and the internet, it has been largely superseded by hybrids of CDMA (code-domain multiple access), TDMA (time-domain multiple access), and SDMA (space-domain multiple access) for digital cellular communication.These are all ITU IMT-2000 (3G) compliant standards and offer data rates up to 2 Mbs for stationary or walking users and 385 kbs for users in a moving vehicle. 3G standards are now being replaced by IMT-Advanced (4G), which offers 100 Mbs for users in a vehicle and 1 Gbs for stationary users. If the user has a data plan associated with the nomadic device, it is possible that the data plan enables broadband transmission and the system could use a much greater bandwidth (thereby accelerating data transfer). In another embodiment, the nomadic device 53 is replaced by a (not shown) cellular communication device installed in the vehicle 31. In yet another embodiment, the ND 53 can be a wireless local area network (LAN) device, for example (and without limitation) via an 802.11g network (i.e.,WiFi) or a WiMax network can communicate.

[0025] In one embodiment, incoming data can be routed through the nomadic device via Data-over-Voice or Dataplan, through the onboard Bluetooth transmitter / receiver, and into the vehicle's internal processor 3. In the case of certain temporary data, the data can be stored, for example, on the HDD or another storage medium 7 until the data is no longer needed.

[0026] Additional sources that can be connected to the vehicle include a personal navigation device 54, which may have, for example, a USB connection 56 and / or an antenna 58; a vehicle navigation device 60 with a USB 62 or other connection; an onboard GPS device 24; or a remote navigation system (not shown) that has connectivity to the network 61. USB is one of a class of serial networking protocols. IEEE 1394 (FireWire™ (Apple), i.LINK™ (Sony), and Lynx™ (Texas Instruments)), EIA (Electronics Industry Association) serial protocols, IEEE 1284 (Centronics Port), S / PDIF (Sony / Philips Digital Interconnect Format), and USB-IF (USB Implementers Forum) form the backbone of device-to-device serial standards. Most of these protocols can be implemented for either electrical or optical communication.

[0027] Furthermore, the CPU could be in communication with various other auxiliary devices 65. These devices could be connected via a wireless 67 or wired 69 connection. The auxiliary device 65 could include, but is not limited to, personal media players, wireless health devices, portable computers, and the like.

[0028] Alternatively, or in addition, the CPU could be connected to a vehicle-based wireless router 73, for example, using a WiFi transmitter / receiver 71 according to IEEE 803.11. This would allow the CPU to connect to remote networks within range of the local router 73.

[0029] In addition to exemplary processes being executed by a vehicle data processing system located in a vehicle, in certain embodiments the exemplary processes can be executed by a data processing system in communication with a vehicle data processing system. Such a system may include, but is not limited to, a wireless device (for example, a mobile phone) or a remote data processing system (for example, but is not limited to, a server) connected by the wireless device. Collectively, such systems can be referred to as a vehicle-associated data processing system (VACS). In certain embodiments, specific components of the VACS can execute specific parts of a process, depending on the specific implementation of the system.For example, and without limitation, if a process involves a step of sending or receiving information with a paired wireless device, then it is likely that the wireless device will not perform the process, since the wireless device would not "send and receive" information to itself. It is understandable to the average professional when it is not appropriate to apply a particular VACS to a given solution. All solutions assume that at least the vehicle data processing system (VCS) located in the vehicle itself is capable of performing the exemplary processes.

[0030] Fig. Figure 2 represents an exemplary system 200 that includes a vehicle 31 designed to play audio content from mobile devices 208 via the VCS 1. As shown, the vehicle 31 includes an operating unit 202 of the VCS 1, designed to provide access to a sound system of the vehicle 31 (for example, as discussed above, to the speakers 13 and the amplifier 11). The system 200 also includes a mobile device 208 that has an audio connection 206 to an external audio input 204 of the VCS 1 to provide sound for playback by the vehicle 31. The mobile device 208 is further connected to the VCS 1 via a data connection 210 and is designed to provide audio cues 214 via the audio connection 206 in response to cue requests 212 received via the data connection 210.It should be noted that this configuration is merely an example and that other layouts can also be used for the vehicle 31, the VCS 1 and the mobile device 208.

[0031] The control unit 202 of the VCS 1 can be configured to provide user control of the vehicle sound system. For example, the control unit 202 can be configured to provide a user interface that allows the selection of an audio input to be played back through the loudspeakers 13 of the vehicle audio system. The control unit can also be configured to provide a user interface that allows the selection of a vehicle volume level at which audio content can be delivered via the vehicle audio system, for example, to control the gain level of the amplifier 11. The control unit can also be configured to provide the user with current status information, such as an indication of the currently active audio input and the current volume level.

[0032] The external audio input 204 can be an auxiliary or other input of the VCS 1 designed to receive audio from a device external to the VCS 1. The external audio input 204 can include, as some non-limiting examples, a wired audio input 204 such as a 1 / 8" headphone jack, a 1 / 4" headphone jack, stereo phono connectors, the audio contacts of a 30-pin iPod connector, or a wireless audio input 204 such as a Bluetooth audio input. A device that supplies sound to the VCS 1 can be connected to the external audio input 204 (for example, via an audio cable between a connected device and the external audio input 204, via a wireless connection, etc.) to establish an audio connection 206 between the device and the VCS 1. The audio connection 206 can therefore be a connection from the mobile device 208 to the VCS 1, via which audio content is provided at a device volume level.The mobile device 208 can be an example of a connected device designed to supply sound to the VCS 1 via the audio connection 206. In some cases, the audio connection 206 can be established from a variable-level output of the mobile device 208 (for example, a headphone output) to the audio input 204 of the VCS 1.

[0033] The data connection 210 can include one or more wired connections (for example, a USB connection) and / or a wireless connection (such as a Bluetooth connection) between the mobile device 208 and the VCS 1. The mobile device 208 can be configured to connect to the VCS 1 via the data connection 210. Consequently, the data connection 210 can be a connection from the mobile device 208 to the VCS 1, through which non-audio data can be provided between the mobile device 208 and the VCS 1. For example, if a user brings a mobile device 208 (for example, a nomadic device 53) that was previously associated with the VCS 1 into the vehicle 31, the VCS 1 can automatically pair with the detected mobile device 208.If the mobile device 208 was not previously paired with the VCS 1, the user can, as another example, use the user interface of the control unit 202 to configure the mobile device 208 for pairing with the VCS 1. Once the mobile device 208 is paired with the VCS 1, the data connection 210 between the nomadic device 53 and the VCS 1 can be configured to allow the VCS 1 and the mobile device 208 to exchange data such as packet-based data information.

[0034] It should be noted that in some cases, both the audio connection 206 and the data connection 210 are routed over the same underlying connection (for example, the same physical connection, the same wireless connection, etc.). In such cases, audio content at a device volume level can be delivered from the mobile device 208 to the VCS 1, and data content can be delivered from the VCS 1 to the mobile device 208 over the same connection. For example, audio and data content can be provided digitally over the same wireless connection between the VCS 1 and the mobile device 208.

[0035] For the vehicle's 31 integrated audio inputs, such as terrestrial broadcast, satellite broadcast, or CD player audio, the VCS 1 can be preconfigured with equalization and gain levels to ensure that the various inputs are provided with a relatively consistent volume level. However, since the audio level for the audio connection 206 can be adjusted from the connected mobile device 208 (for example, the nomadic device 53), there can be significant differences in the actual audio volume ultimately offered to the user via the vehicle's sound system compared to the volume level supplied by another input. This can be problematic when the user switches between inputs, as the volume level may deviate drastically from the user's expectations.This may still pose a problem for the user when adjusting the volume settings of the VCS 1, as it may be unclear to the user how loud the sound from the mobile device 208 will be played back by the vehicle sound system, even though the VCS 1 provides an indication of its own volume level (for example, audible after changing the vehicle volume setting or via display 4).

[0036] To enable the user to hear the overall volume level, the VCS 1 can be configured to send a notification request 212 to the mobile device 208 via data connection 210. This notification request 212 can then cause the mobile device 208 to play the audio notification 214 via audio connection 206, reflecting the current volume level of the mobile device 208. The audio notification 214 can be a previously recorded or generated sound used to indicate the overall volume level to the user. For example, the audio notification 214 could be a beep or a bell tone. The user can hear the audio notification 214 requested and played back by the VCS 1 and can thus gauge the overall volume level for the sound supplied by the mobile device 208.

[0037] To allow the user to anticipate the overall volume level that can be provided when changing the volume setting, the audio cue 214 can be requested by the VCS 1, for example, upon receiving a user command that changes the audio system volume. As another way to inform the user about the overall volume level when switching between inputs, the audio cue 214 can be requested by the VCS 1 in response to the user switching to audio input 204. Accordingly, the VCS 1 can accurately convey to the user the actual volume that will be heard as soon as the user changes the vehicle volume, without the need for complex algorithms and calculations.

[0038] Fig. Figure 3 presents an exemplary process 300 for requesting audio cues 214 for a volume level by the VCS 1, which are to be supplied by the mobile device 208. The process 300 can, for example, be carried out by the VCS 1 in communication with the mobile device 208 via the audio connection 206 and the data connection 210.

[0039] During operation 302, the VCS 1 receives a setting change notification. For example, the VCS 1 may receive a notification from the control unit 202 that the user has changed the current volume level of the VCS 1. As another example, the VCS 1 may receive a notification from the control unit 202 that the user has selected the external audio input 204 as the sound source for the vehicle audio system.

[0040] During operation 304, VCS 1 sends the alert request 212 to the mobile device 208 via data connection 210. In some cases, the alert request 212 may include a sound to be played back by the mobile device 208. In other cases, the alert request 212 may refer to a sound stored or generated by the mobile device 208 that is to be played back by the mobile device 208. In still other cases, the alert request 212 may not specify a sound, and the mobile device 208 may simply use a generated or stored sound that the mobile device 208 is designed to provide in response to alert requests 212.

[0041] During operation 306, the VCS 1 receives the audio cue 214 from the mobile device 208 via audio connection 206. The audio cue 214 can then be delivered to the VCS 1 as a sound using the current volume level settings of the mobile device 208.

[0042] During operation 308, the VCS 1 reproduces the audio cue 214 at the current VCS volume level. For example, the VCS 1 plays the audio cue 214 through the speakers 13 of the vehicle audio system. The user can therefore hear the audio cue 214 requested by the VCS 1 and can experience the overall volume level for sound supplied by the mobile device 208. Process 300 ends after operation 308.

[0043] Fig. Figure 4 presents an exemplary process 400 for providing audio cues 214 for a volume level of the mobile device 208 as requested by the VCS 1. Process 400 can, for example, be carried out by the mobile device 208 in communication with the VCS 1 via the audio connection 206 and the data connection 210.

[0044] During operation 402, the mobile device 208 receives the alert request 212 over the data connection 210 to deliver the audio alert 214 over the audio connection 206. In some cases, the alert request 212 may contain a sound to be played by the mobile device 208, while in other cases, the alert request 212 instructs the mobile device 208 to play a sound stored on the mobile device 208. (The stored sound may have been previously delivered to the mobile device 208 by the VCS 1, for example, in a previous alert request 212 delivered by the VCS 1 to the mobile device 208, in another message delivered to the mobile device 208 before the alert request 212, etc.)) In still other cases, the alert request 212 may not specify a sound, and the mobile device 208 may simply use a generated or stored sound that the mobile device 208 is designed to provide in response to alert requests 212.

[0045] During operation 404, the mobile device 208 delivers the audio cue 214 to the VCS 1 via the audio connection 206. The mobile device 208 can therefore return the audio cue 214 to the VCS 1 at a level consistent with its volume level settings.

[0046] During operation 406, the mobile device 208 delivers audio content to the VCS 1 via audio connection 206. The user can therefore hear the audio content at the same relative volume level as the audio cue 214 requested by the VCS 1. After operation 406, process 400 ends.

[0047] In general, computer systems and / or devices, such as the VCS 1, can use any of a number of computer operating systems, including, but in no way limited to, versions and / or variants of the Microsoft Windows® operating system, the Unix operating system (for example, the Solaris® operating system distributed by Oracle Corporation of Redwood Shores, California), the AIX UNIX operating system distributed by International Business Machines of Armonk, New York, the Linux operating system, the Mac OS X and iOS operating systems distributed by Apple Inc. of Cupertino, California, the BlackBerry OS distributed by Research In Motion of Waterloo, Canada, and the Android operating system developed by the Open Handset Alliance.Examples of computer equipment include, but are not limited to, a computer workstation, a server, a desktop, notebook, laptop or handheld computer, or other computer systems and / or devices.

[0048] Computer devices such as the VCS 1 and the Mobile Device 208 generally contain computer-executable instructions, which can be executed by one or more computer devices such as those listed above. Computer-executable instructions can be compiled or interpreted by computer programs using a variety of programming languages ​​and / or technologies, including, but not limited to, Java™, C, C++, C#, Objective-C, Visual Basic, JavaScript, Perl, etc., either alone or in combination. Generally, a processor (for example, a microprocessor) receives instructions from, for example, memory, a computer-readable medium, etc., and executes the instructions, thereby performing one or more processes, including one or more of the processes described herein. Such instructions and other data can be stored and transmitted using a variety of computer-readable media.

[0049] A computer-readable medium (also called a processor-readable medium) includes any non-perishable (for example, tangible) media that participates in providing data (for example, instructions) that can be read by a computer (for example, by a computer's processor). Such a medium can take many forms, including non-volatile and volatile media. Non-volatile media can include, for example, optical or magnetic disks and other permanent storage devices. Volatile media can include, for example, Dynamic Random Access Memory (DRAM), which typically forms main memory. Such instructions can be transmitted through one or more transmission media, including coaxial cables, copper wires, and optical fibers, including the wires that comprise a system bus connected to a computer's processor.Common forms of computer-readable media include, for example, a floppy disk, a diskette, a hard disk, magnetic tape, any other magnetic medium, a CD-ROM, a DVD, any other optical medium, punched cards, paper tape, any other physical medium with hole patterns, a RAM, a PROM, an EPROM, a FLASH EEPROM, any memory chip or plug-in module, or any other medium that a computer can read. Key to symbols Fig. 1 4 Display 11 amplifiers 25 Auxiliary entrance 51 input selectors 52 BT pair 54-person navigation device 60 vehicle navigation devices. 61 network 65 Auxiliary device 71 Wireless module Fig. 2 212 Notice request 214 Audio note

Claims

[1] System (1), comprising: a vehicle sound system connected to a mobile device (208) via a data connection (210) and an audio connection (206), and designed to request, via the data connection (210), that the mobile device (208) provide an audio cue (214) with the current volume level of the mobile device (208) via the audio connection (206) in response to a change in the volume level of the vehicle sound system, and to reproduce the audio cue (214) with the volume level of the vehicle sound system to indicate a loudness for sound played from the mobile device (208). [2] System (1) according to claim 1, wherein the vehicle sound system is further designed to reproduce audio content provided by the mobile device (208) at the displayed loudness. [3] System (1) according to claim 1, wherein the vehicle sound system is further designed to provide the audio cue (214) via the data connection (210) for playback by the mobile device (208). [4] System (1) according to claim 1, wherein the audio cue (214) is stored by the mobile device (208) and the request via the data connection (210) includes a cue for the mobile device (208) to play the audio cue (214) stored by the mobile device (208). [5] System (1) according to claim 1, wherein the change in the volume level of the vehicle sound system is made in response to the receipt of a command to adjust the volume level of the vehicle sound system. [6] System (1) according to claim 1, wherein the change in volume level of the vehicle sound system occurs in response to receiving a command to switch an audio input (204) of the vehicle sound system to play sound from the mobile device (208). [7] System (1) according to claim 1, wherein the data connection (210) includes a USB connection (56) between the mobile device (208) and the vehicle sound system and / or a Bluetooth connection between the mobile device (208) and the vehicle sound system. [8] System (1) according to claim 1, wherein the audio connection (206) comprises a wired audio connection (206) between the mobile device (208) and the vehicle sound system and / or a wireless audio connection (206) between the mobile device (208) and the vehicle sound system. [9] System (1) according to claim 1, wherein the audio cue (214) can be a beep or bell tone. [10] System (1) comprising a mobile device (208) connected to a vehicle sound system via a data connection (210) and an audio connection (206) and designed to receive a request from the vehicle sound system via the data connection (210), to provide an audio cue (214) via the audio connection (206), and to provide the audio cue (214) via the audio connection (206) with a volume level from the mobile device (208) to cause the vehicle sound system to reproduce the audio cue (214) with the volume level of the vehicle sound system to indicate a loudness for a sound played from the mobile device (208). [11] Method comprising: in response to a change in the volume level of a vehicle sound system connected to a mobile device (208) via a data link (210) and an audio link (206), requesting via the vehicle sound system that the mobile device (208) provide an audio cue (214) via the audio link (206), and reproducing the audio cue (214) at the volume level of the vehicle sound system by the vehicle sound system to indicate a loudness for a sound played by the mobile device (208) via the vehicle sound system.

Images