WO2016156702A1 - Amelioration d'emission de flux multimedia - Google Patents

Amelioration d'emission de flux multimedia Download PDF

Info

Publication number
WO2016156702A1
WO2016156702A1 PCT/FR2016/050653 FR2016050653W WO2016156702A1 WO 2016156702 A1 WO2016156702 A1 WO 2016156702A1 FR 2016050653 W FR2016050653 W FR 2016050653W WO 2016156702 A1 WO2016156702 A1 WO 2016156702A1
Authority
WO
WIPO (PCT)
Prior art keywords
multimedia
stream
processor
mdev
buffer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/FR2016/050653
Other languages
English (en)
Inventor
Damien Plisson
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to EP16718407.6A priority Critical patent/EP3274830A1/fr
Priority to JP2017549809A priority patent/JP2018520398A/ja
Priority to US15/558,079 priority patent/US20180052786A1/en
Publication of WO2016156702A1 publication Critical patent/WO2016156702A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/16—Handling requests for interconnection or transfer for access to memory bus
    • G06F13/1668—Details of memory controller
    • G06F13/1673—Details of memory controller using buffers
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/16—Handling requests for interconnection or transfer for access to memory bus
    • G06F13/1668—Details of memory controller
    • G06F13/1689—Synchronisation and timing concerns
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory

Definitions

  • the invention relates to improving the transmission of multimedia streams, including audio streams.
  • Increasing the power of micro-computers, portable computers and tablets has enabled the development of real-time processing of audio recordings whose main purpose is to correct technical defects. playback and recording on CD and SACD media and to improve the purity of sound by eliminating noise due to scanning itself and interference introduced by the various components of the recording and reproduction chain .
  • the invention improves the situation.
  • One aspect of the invention relates to a method of transmitting multimedia streams to a multimedia device of a computer, the computer comprising a processor adapted to operate in a user mode and in a mode supervisor, the computer comprising a processor readable storage medium and storing a medi um model, the transmission method including an implementation, by the multimedia module executed by the processor in supervisor mode: / a / kernel space allocation of a buffer arranged to contain at least ten seconds of multimedia stream;
  • This method is particularly advantageous in that it improves the quality of sound and / or video included in a multimedia stream emitted by such a method.
  • the method gives it a very high priority for the real-time management of the multimedia stream.
  • the method ensures a greater continuity in the transmission of the multimedia stream, which is less likely to be interrupted (even for very short periods), thus also ensuring a higher quality of broadcast.
  • the use of kernel space implies (compared to a use of the user space) reduced use of memory and processor resources because it requires fewer memory area recopies and less processor context changes. , which are likely to generate electrical and electromagnetic interference when transmitting a multimedia stream.
  • Another aspect of the invention relates to a computer program comprising a series of instructions which, when executed by a processor, implement a method according to one aspect of the invention.
  • Another aspect of the invention relates to a storage medium not computer-readable transient comprising a computer program according to one aspect of the invention.
  • a multimedia stream transmission system comprising a computer and a multimedia device, the computer comprising a processor adapted to operate in user mode and in supervisor mode, the computer comprising a medium processor-readable storage device and storing a multimedia module, the multimedia module being arranged to be executed by the processor in supervisor mode, the transmission system comprising:
  • a reception circuit of a multimedia stream arranged to receive said multimedia stream and store it in the buffer memory; a transmission circuit of a multimedia stream stored in the buffer memory to the multimedia device.
  • This system is advantageous in that it is particularly suitable for the implementation of a method according to the invention, and thus makes it possible to improve the quality of the sound and / or the video included in a multimedia stream when the issue of the latter.
  • FIG. 1 illustrates a multimedia stream transmission system according to one embodiment
  • FIG. 2 diagrammatically illustrates the contents of a memory MEM according to one embodiment
  • FIG. 3 illustrates a method of transmitting multimedia streams according to one embodiment
  • Figure 4 illustrates the architecture of a system according to one embodiment
  • Figure 5 illustrates a procedure for initializing a method according to one embodiment
  • Figure 6 illustrates an audio playback according to one embodiment
  • Figure 7 illustrates an automatic pause according to one embodiment
  • FIG. 8 illustrates a method of detecting and processing the end of transmission of a piece of music according to one embodiment
  • FIG. 9 illustrates a method of stopping transmission of a piece of music according to one embodiment
  • Figure 10 illustrates a kernel space buffer according to one embodiment.
  • the embodiments are often related to an audio stream, but these embodiments also apply to other types of streams.
  • Figure 1 illustrates a PC computer including an HDD hard disk, an MDEV multimedia device and a motherboard.
  • the multimedia device MDEV can be integrated into the motherboard.
  • the multimedia device MDEV comprises a digital analog converter DAC, for example for converting digital data from a multimedia stream MUS (encoding music, which may be the audio part of a video stream) into an electrical voltage able to control a loudspeaker (in order to reproduce with the loudspeaker the music encoded in the MUS multimedia stream, if necessary after amplification by an amplifier).
  • DAC digital analog converter DAC
  • the motherboard is equipped with an MP processor (whose cooling system is not shown) and at least one MEM memory chip (for example a DDR3 SDRAM DIMM).
  • the motherboard is also equipped with five circuits AL_C, REC_C, EM_C, RES_C and SND_C. These circuits are represented as discrete discrete electronic components. However, according to one possible implementation, the functions of these five circuits are fulfilled by a single circuit providing these various functions. According to one possible implementation the five circuits are implemented by a circuit consisting of the meeting of the processor MP and the memory MEM containing specific programs, in a manner described more precisely in the following description.
  • the motherboard also includes a storage connector (SATA,
  • a bus (not shown) connects the different components of the motherboard
  • the microprocessor MP the memory MEM, the multimedia device MDEV, the hard disk HDD, and the various circuits AL_C, REC_C, EM_C, RES_C and SND_C).
  • FIG. 2 schematically illustrates the contents of a memory MEM according to a possible embodiment.
  • the memory represented is addressed in 32-bit mode (as illustrated by the initial address 0x00000000), but can of course be addressed in 64-bit or according to any other appropriate addressing.
  • the memory MEM contains, from a first physical address, an executable code corresponding to an MPL multimedia player implemented in software form.
  • the memory MEM contains, from a second physical address, an executable code corresponding to a multimedia module MM.
  • This multimedia module MM contains an INT interface, which can take the form of an API, namely a standardized set of classes, methods or functions that serves as a facade by which software provides services to other software.
  • the memory MEM contains, from a third physical address, an executable code corresponding to a buffer memory BUF.
  • the three memory ranges storing the above information are each represented as being continuous ranges. However, in practice they are not necessarily so.
  • FIG. 2 represents information stored according to their physical addresses.
  • Virtual addresses (which are usually distributed by a processor-integrated MMU and allow for abstraction of physical addresses) may be different from physical addresses (and usually are).
  • Figure 3 illustrates a method of transmitting multimedia streams according to a possible embodiment.
  • a multimedia module MM performs an exclusive reservation of an MDEV multimedia device.
  • An arrow is symbolically directed from the multimedia module MM to the media device MDEV.
  • the multimedia device thus receives a request which it processes for example using a microcontroller integrated in the multimedia device. But the exclusive reservation does not necessarily reach the multimedia device.
  • the request is for example directed to a device driver of the multimedia device, which manages the exclusive reservation of the multimedia device and may not even inform the multimedia device of its exclusive reservation.
  • the multimedia module can automatically release the multimedia device (in order to stop the exclusive reservation).
  • the multimedia module MM allocates a large BUF buffer in kernel space.
  • the multimedia module MM receives (in the form of a data block) an extract of a multimedia stream (for example a few seconds of MUS music or MOV video) from a network. MPL media player. It saves this excerpt in the BUF buffer. If necessary, it receives such extracts as long as the buffer memory is not filled.
  • the multimedia module MM transmits (in the form of a data block) a multimedia stream extract contained in the buffer BUF to the multimedia device MDEV. As soon as the buffer has been filled, part of its contents has been emitted, the multimedia module MM is arranged to receive again multimedia stream extracts until the buffer is filled again.
  • the portions of multimedia streams transmitted do not necessarily coincide exactly with the parts of multimedia streams received. For example, it is possible to receive a multimedia stream in blocks of 3 kilobytes and send them in blocks of 2 kilobytes. The size of the blocks received and emitted is not necessarily constant. Thus, although the received stream and the transmitted stream are globally identical, their division (in data blocks for reception and in data blocks for transmission) is not necessarily so.
  • multimedia stream For convenience of writing, parts of the multimedia stream will be referred to by the term "multimedia stream". Indeed, a part of flows multimedia remains a multimedia stream.
  • the media player (MPL) communicates, via an interface (INT) of the multimedia module MM, a request to select any read position in the buffer memory (BUF).
  • INT interface
  • the buffer memory BAF
  • FIG. 4 illustrates the architecture of a system according to an embodiment.
  • An MPL audio application that is loaded at the application level (in user space) reads a large amount of data representing a piece of music from an audio data source (DVD, remote server, local file, etc.). It then transfers this data as small packets into a BUF buffer of an MM audio player (a particular type of multimedia module) that is loaded at the kernel level (in kernel space). It operates this data transfer via an interface INT, which also serves to send commands to the audio player MM kernel and to receive notifications from him.
  • the MM kernel audio player in turn transfers this data to a DRV device driver of an MDEV audio device.
  • the DRV device driver is either external to the MM kernel audio player or is directly integrated into the MM kernel audio player.
  • the data is then transferred to an IO input / output interface, and then to the MDEV audio device.
  • Figure 5 illustrates a procedure for initializing a method according to an embodiment.
  • An MPL audio application executed in user space sends an HQ_MOD request to a kernel MM audio player (executed in kernel space) to switch to audiophile playback mode (high quality mode). Yes necessary, the MPL audio application first loads the audio player of the MM kernel into kernel space.
  • the MM kernel audio player sends an exclusive reservation request S_RES of an MDEV audio device to an audio service of the kernel. This request leads to a disconnection of the rest of the audio system to neutralize any other request addressed to the MDEV audio device and not coming from the audio player of the kernel.
  • the kernel audio service responds to the MM kernel audio player by transmitting an S_RES_OK notification that the exclusive reservation has been successfully completed.
  • the audio player of the MM kernel sends a REQ_F request to the MDEV audio device so that it communicates to it the different formats that it supports (sampling rate at 44, 1 kHz for a CD quality, at 96 kHz, number of supported channels , etc.). The latter responds by sending the supported formats in an SND_F message.
  • the audio player of the MM kernel then performs an AL allocation of a BUF buffer used for the audio data. This buffer is a large buffer (at least ten seconds of audio data).
  • the audio player of the core MM then signals to the audio application MPL, using an HQ_MOD_OK message, that the transition to audiophile mode has been correctly performed.
  • Figure 6 illustrates an audio playback method according to one embodiment.
  • an MPL audio application first sends a configuration message CONF1 to an audio player of the MM kernel.
  • the content of this message can be determined during an initialization procedure as shown in FIG. 5.
  • the configuration message CONF1 can thus specify, for example, that the piece of music that will be transmitted is sampled on 24 bits, at a time. frequency of 96 kHz, and that it is stereophonic. Of course, other formats can be employees.
  • the MM kernel audio player transmits a CONF2 configuration message to an MDEV audio device.
  • This CONF2 message can take back the elements received in the CONF1 message, and may if necessary be subject to prior processing.
  • the MDEV audio device responds that it has been successfully performed by an OK2 message to the MM kernel audio player, which in turn informs the MPL audio application with a OK1 message.
  • the audio application MPL proceeds then (step LD) to a loading of audio data in the buffer BUF of the audio player of the core MM.
  • the audio application MPL sends an RD1 message to the audio player of the MM kernel to ask it to start reading the data.
  • audio that is, sending them to the MDEV audio device for broadcast on loudspeakers.
  • the MM kernel audio player starts playback by sending an RD2 message to the MDEV audio device.
  • the reading process then triggers a loop which repeats in principle until the end of the audio data of the piece of music to be played is reached (ie until the entire piece of music has been played). been treated).
  • This loop includes sending, by the audio device MDEV to the audio player of the MM kernel, a request RQ_PK requesting the sending of a packet of audio data.
  • the audio player responds by sending the requested packet with an SND_PK message, and increments (at a step INC) the read position in the BUF kernel buffer so that the next read in that kernel buffer matches at the beginning of the next packet.
  • the transmitted packets are constructed from the data extracted from the buffer.
  • the packets comprise other information (such as a header indicating, for example, a packet size, a cyclic redundancy code, etc.).
  • the audio device MDEV comprises a digital analog converter DAC operating synchronously.
  • the audio player of the MM core is then arranged to send the audio data without a request, by itself deciding the sending frequency, according to the settings of the MDEV audio device.
  • the audio player of the MM kernel Periodically (for example every second), notifies the MPL audio application of the reading position by means of a NOT_POS message. Alternatively (or in addition, when it is useful), the audio application MPL can itself access this information for example using the INT interface of the audio player of the kernel (without waiting to receive a notification ).
  • the MPL audio application based on received NOT_POS notifications and / or stream information that it read directly (without recourse to such notifications), completes (step CONT_LD) the BUF kernel buffer ( as long as the piece of music has not been fully broadcast).
  • Figure 7 illustrates an automatic pause when waiting for data, according to one embodiment.
  • the audio player of the MM kernel is arranged to detect that the reading position by the audio player of the MM kernel in the buffer of the BUF kernel reaches a position corresponding to the end of the loaded audio data, but which is neither the position of the end of the song, or the end of the buffer. For example, it operates this detection by detecting an event EMPTY_BUF (event triggered when the INC increment of the read position illustrated in FIG. 6 reaches the end position of the audio data in the buffer memory), or a software interrupt, or by a continuous test loop performed by a separate thread (a thread is sometimes called a "task” or a "thread” in French).
  • EMPTY_BUF event triggered when the INC increment of the read position illustrated in FIG. 6 reaches the end position of the audio data in the buffer memory
  • a software interrupt or by a continuous test loop performed by a separate thread (a thread is sometimes called a "task” or a "thread” in French).
  • the kernel audio player then sends the audio device MDEV a paused RQ_PSE request (so that the audio device stops soliciting audio packets).
  • the MDEV audio device responds with a PSE_OK message that the pause was successful.
  • the audio player of the MM kernel then notifies the MPL audio application, by a notification NOT_PSE, that the MDEV audio device paused for lack of data.
  • the audio player of the MM kernel instead of sending a pause request RQ_PSE to the MDEV audio device, the audio player of the MM kernel sends it "silence" packets (ie, packets containing constant samples representing a null signal, corresponding to silence) until the buffer BUF again has enough data.
  • This alternative has the advantage of increased interoperability with any type of audio device (the audio device not being aware of pausing, which is simulated).
  • the kernel audio player then continues to check the contents of the kernel buffer by a mechanism similar to that which allows it to detect that there is no more data in this kernel buffer. As soon as a sufficient amount of data is detected, for example by using a BUF_FILL event, the kernel reader transmits a message RES_RD to the audio device MDEV so that it resumes reading.
  • the audiophile M M DEV responds to the idea of a RES_RD_OK message that it has resumed reading, which the MM audio player notifies to the MPL audio application using a NOT_RD notification.
  • FIG. 8 illustrates a method for detecting and processing the end of transmission of a piece of music according to one embodiment.
  • An audio player of the MM kernel is arranged to detect that the reading position by the audio player of the MM kernel in a buffer of the BUF kernel reaches a position corresponding to the end of this buffer, or at the end of a piece played . For example, it operates by detecting a REACH_END event, by a software interrupt, or by a continuous test loop performed by a separate thread.
  • the kernel audio player then sends a NOT_END notification to an MPL audio application that the kernel buffer is playing or the song is playing
  • the audio application MPL checks (step TST_MORE_DAT) if audio data is present after this position, or in a next buffer (when there are several buffers). If so, it continues reading from the current or next buffer as appropriate (step CONT RD). Otherwise (step NO_MORE_DAT), the audio player of the kernel sends the audio device MDEV a PSE request for pausing (so that the audio device stops soliciting audio packets). The MDEV audio device responds with an OK_PSE message that the pause has been successful.
  • the MM kernel audio player then notifies the MPL audio application, through a NOTIF_P notification, that the MDEV audio device has paused for lack of data.
  • the audio player of the MM kernel lu i instead of sending a PSE request to pause the MDEV audio device, the audio player of the MM kernel lu i sends packets of silence, as previously indicated. This allows you to automatically switch from playing the end of a song to playing the beginning of a next song.
  • Figure 9 illustrates a method of stopping transmission of a piece of music according to one embodiment.
  • An MPL audio application requires a MM kernel audio player to stop playback of a piece of music by an MDEV audio device, using a RQ_STP1 request.
  • the MM kernel audio player requires the MDEV audio device to stop playing the piece of music, using a RQ_STP2 request.
  • the MDEV audio device responds to the MM kernel audio player that it has stopped playing with an STP2_OK message.
  • the MM kernel audio player notifies the MPL audio application that it has stopped playing with an STP1_OK message.
  • the audio application MPL then asks the audio player MM, using an RQ_NM message, to return to normal (non-audiophile) mode.
  • the MM kernel audio player asks a kernel audio service to using an RQ_RECONF1 request, a reconfiguration of the MDEV audio device.
  • the kernel audio service requests the MDEV audio device, using an RQ_RECONF2 request, for the required reconfiguration.
  • the MDEV audio device responds to the kernel audio service, using a RECONF2_OK notification that it has successfully reconfigured.
  • the kernel audio service notifies the audio player of the MM kernel, using a RECONF1_OK notification that the MDEV audio device is reconfigured (and ready for use again).
  • the audio player of the MM kernel then requests the kernel audio service, using a request RQ_FR, to stop the exclusive reservation of the MDEV audio device.
  • the kernel audio service responds with a FR_OK notification that it has stopped this exclusive reservation.
  • the MM kernel audio player notifies the MPL audio application.
  • the audio player of the MM kernel can then be unloaded from the kernel, and it can previously release the kernel mode buffer (UNLD stage).
  • the control of the MDEV audio device can then be returned to the operating system.
  • Figure 10 illustrates a kernel space buffer according to one embodiment.
  • the illustrated buffer includes audio data being played.
  • the current reading position is identified by a pointer RD_POS.
  • the end of the audio data loaded into the buffer is identified by a pointer POS_END_LD_AU.
  • the end position of the song (assuming it is in the buffer) is identified by a pointer POS_END_AU.
  • the end position of the buffer is identified by a pointer POS_END_BUF.
  • a first embodiment relates to a method of transmitting multimedia streams (such as a MUS music stream, or MOV video stream) via an MDEV multimedia device of a PC computer.
  • the multimedia device which is a hardware device (for example a sound card, a graphics card, or a combination of both), is an integral part of the computer.
  • the multimedia device is external to the computer and is simply connected to it (by wired or wireless link).
  • the computer is for example a personal computer (laptop or desktop), but it can also be for example a mobile phone, a tablet, an MP3 player, a connected watch, a server or a network drive.
  • a network reader constitutes all or part of an integrated box containing both a computer part (able to read a multimedia stream from an internal storage and / or from a computer network) and a HIFI part. capable of rendering a multimedia stream in a manner perceptible to a human ear.
  • the computer comprises at least one MP processor adapted to operate in user mode and in supervisor mode (it may be a multicore or single-core processor).
  • the processor checks (under control of the operating system) fairly strictly the access to the resources (memory, peripherals, etc.), which makes it possible in particular to avoid that software (executed in this mode) user mode) takes up resources, causes the computer to crash, or gains access to confidential information that it is not supposed to access.
  • This user mode is the default mode used by software. However, the fact that the user mode is subject to increased checks means that this user mode is slower and less responsive.
  • memory is allocated by software running in user mode, it is allocated in the user space (a space in which the memory of other software and the operating system is not accessible).
  • kernel space is a space in which all resources are visible.
  • kernel space is a space in which all resources are visible.
  • the kernel space it is thus possible to consult the portions of physical memory used by all the software programs executed by the computer, and even to make changes to it (erasing information, replacing them, etc.). i can be very dangerous.
  • supervisor mode also known as kernel mode
  • Kernel mode is therefore normally reserved for the kernel of the operating system, a kernel that manages low-level functions (device drivers, access to hardware, etc.).
  • the computer comprises a storage medium (such as a magnetic hard disk HDD, or an SSD, sometimes called an electronic disk, composed of memory such as flash memory, or any other type of disk. storage medium) readable by the processor and storing a multimedia module MM.
  • the MM multimedia module is for example the result of the compilation of a program written in a language ensuring fairly high performance (in contrast to certain interpreted languages for example), such as the C or C ++ language.
  • the multimedia module can even be the result of the assembly of a software written directly in assembly, which can allow an additional optimization of the performances.
  • the multimedia module can also be mixed, in the sense that it can result from the compilation of a program written partly in a language such as the C language but some parts of which (critical from the point of view of the performance) are written directly into assembler.
  • the multimedia module MM is designed to be executed by the processor
  • This multimedia module is for example integrated into the core of an operating system installed on the computer, which can be a conventional operating system, for example of the Microsoft Windows, Linux, OS X, Android, iOS, Windows Phone type. , BlackBerry, Symbian, etc.
  • This multimedia module can for example be integrated with a device driver, in particular a device driver managing the multimedia device MDEV.
  • This multimedia module can alternatively be installed at the same level as such a device driver (without being integrated).
  • the multimedia module can also be integrated into a dynamically loaded kernel extension (on demand), or integrated directly into a monolithic kernel (so it is possible to compile a kernel specifically for this purpose).
  • Running the media module in supervisor mode gives it increased performance. In particular, he may have priority over other modules run in parallel but in user mode.
  • the execution in supervisor mode makes it possible to improve the speed of response to requests from the multimedia device (which can notably issue requests for receiving the rest of a multimedia stream that it is playing). This improves the temporal accuracy of the signal carried by the multimedia stream, thanks to the priority of the multimedia module on all modules executed in user mode, especially since the execution of the response process does not require in this case to call routines present in user mode. Since the activity necessary for transmitting the multimedia stream in supervisor mode is less than the activity necessary to emit the multimedia stream in user mode, it reduces the (especially electromagnetic) noise associated with this activity.
  • the transmission method comprises an implementation, by the multimedia module, of an allocation, in kernel space, of one (or, alternatively, several) buffer memory (s) BUF arranged (s) to contain (collectively , if there are several) at least ten seconds of multimedia stream.
  • This buffer in addition to being in kernel space, and has a size much higher than in the prior art which ensures continuity when remission of a multimedia stream.
  • the multimedia stream transmitted by the multimedia module to the multimedia device takes the form of data, which are, before reaching the multimedia device, likely to pass through several intermediate elements, in particular by a device driver of the multimedia device and by modules of a kernel of a computer operating system.
  • New data is regularly stored in the buffer (likely to be used by such modules of the kernel) to ensure the continuity of the broadcast of the multimedia stream.
  • the use of an unconventional size (corresponding to at least ten seconds of multimedia fl ow) for this buffer makes it possible in particular to carry out data transfers (from a multimedia stream source, such as a multimedia player, to the multimedia module) of a much larger unit size, and therefore to greatly reduce the number of these transfers during transmitting the multimedia data to the multimedia device. This greatly limits the additional activity generated to request new data and transmit it. This correlatively reduces the electromagnetic interference generated by this additional activity.
  • the large size of the buffer is thus advantageous in that any disturbance temporarily preventing data from a multimedia source can be compensated for a period of up to ten seconds minimum.
  • the threshold of ten seconds is not strict and must be understood as meaning: approximately ten seconds (for example, nine seconds may suffice).
  • the duration of the buffers of the prior art is less than one second, and that of the buffer memory according to the invention differs in that it is much longer (at least ten times longer).
  • Such a duration seems sufficient to counter the effects on the emission of a multimedia stream of phenomena likely to slow or disrupt strongly but very temporarily the computer.
  • Such phenomena may be related for example to a temporary lack of RAM.
  • This virtual memory is based on a mass storage medium, much slower than the RAM but much larger capacity (typically a hard disk).
  • swap memory the word “swap” meaning "exchange” in English
  • This operation of "swap memory” which can be long, can then cause (in the context of previous solutions) a cut in the broadcast of the multimedia stream.
  • the use of a large buffer makes it possible to absorb "swap memory” punctually required without interruption in the transmission of the multimedia stream. Such phenomena may also be related to preparatory phases for the automatic execution of background tasks.
  • the transmission method comprises an implementation, by the multimedia module, of a reception of a multimedia stream (for example from a remote server, via a network, or from a local storage such as a local hard disk or a USB key), and its storage in the buffer.
  • This multimedia stream is understood as a portion of multimedia stream corresponding to the capacities of the buffer memory.
  • the transmission method comprises an implementation, by the multimedia module, of a transmission of a multimedia stream stored in the buffer memory BUF to the multimedia device. According to one possible implementation, this transmission takes place by transmission of small stream packets multimedia from the buffer BUF, the size of said packets being fixed by multimedia device MDEV.
  • the multimedia stream can come from any origin. It can come from a file stored in the computer, but it can also come from an external entity, for example a remote server (for example using a technique called "streaming", sometimes called in French direct flow, streaming, streaming, streaming or streaming).
  • a remote server for example using a technique called "streaming", sometimes called in French direct flow, streaming, streaming, streaming or streaming.
  • a multimedia stream transmission method comprises an implementation by the multimedia module MM of an exclusive reservation RES of the multimedia device MDEV during the transmission of the stream.
  • multimedia the multimedia module MM of an exclusive reservation RES of the multimedia device MDEV during the transmission of the stream.
  • the transmission of multimedia streams is continuous (except intervention of a user requesting for example a pause), and the reservation remains exclusive until the end of the transmission of the entire multimedia stream considered (eg until the end of the full broadcast of an entire movie).
  • the exclusive reservation can take place as a prerequisite for the broadcast of the entire multimedia stream (just before the start of a movie for example), and subsist throughout the movie (which includes numerous receptions of multimedia stream and broadcast parts). of parts of multimedia streams), without that it is not necessary to make an exclusive reservation again each time a new part of the multimedia stream is received (the initial exclusive reservation persists).
  • the exclusive reservation takes place at the kernel level of an operating system installed on the computer.
  • This implementation includes replacing a media device driver or a kernel module controlling the multimedia device with a new device driver (respectively a new kernel module) incorporating a function to deny any connection of a device. application other than a specified multimedia source.
  • the multimedia source is for example a media player (in the form of an application module), only this application module being authorized by the new device driver (respectively driver).
  • the function takes as input parameter an identifier of the multimedia source as well as a bit whose value indicates that an exclusive reservation is required, and the other value indicates that the exclusive reservation does not is no longer required.
  • this function is secured, for example by predefining the multimedia source (s) authorized to request an exclusive reservation and prohibiting any application other than that contained in the list of authorized predefined applications of make an exclusive reservation.
  • there is only one authorized source and the function does not take as an input parameter the identifier of this source.
  • the set (or alternatively a part) of the device driver (or kernel module) functions relating to the multimedia stream em ission is modified so that these functions return a code of error when an exclusive reservation has been made and when it identifies that the calling application module is not the one for which an exclusive reservation has been requested.
  • the exclusive reservation takes place at the kernel of an operating system installed on the computer, as follows.
  • an interface module that interfaces between modules applications and kernel-level multimedia device drivers is replaced by a new interface module incorporating a function for denying any connection of an application other than a specific multimedia source, in a manner similar to that indicated in paragraph previous.
  • the exclusive reservation operates at the application level of an operating system installed on the computer.
  • the operating system provides a function to reserve exclusive access to the multimedia device.
  • a multimedia source such as the application media player calls this function of the operating system to operate an exclusive reservation.
  • the buffer memory is a cyclic buffer.
  • the media module maintains a media stream start pointer (pointing to a portion of the media stream contained in the cyclic buffer and about to be transmitted) and a media stream end pointer (which may be the same as the start pointer). of multimedia fl ows if the cyclic buffer is full).
  • the zero value is set to the start pointer of the multimedia stream (independently of the memory address corresponding to the beginning of the multimedia stream). For example, consider a cyclic buffer of 1764000 bytes (0x1AEAA0 bytes in hexadecimal notation), occupying a memory area ranging from 0x03000000 to 0x031AEA9F. Such a cyclic buffer can thus contain ten seconds of sampled stereo audio stream at 16 bits per channel, at a frequency of 44.1 kHz. The beginning of the multimedia stream may thus be within the range of between 0x03000000 and 0x031AEA9F (for example, the address 0x0305ABE6).
  • the multimedia module MM of a multimedia stream transmission method comprises an interface I NT accessible from a multimedia player MPL executed by the MP processor in user mode, the transmission method comprising an SND sending to the multimedia module ia MM, by the multimedia player MPL, via said interface INT, a request to select any read position in the buffer memory BUF.
  • the multimedia module makes it possible to select a reading position at an arbitrary position in the buffer memory, and not simply a predefined position such as the beginning of the buffer memory. This is particularly advantageous in view of the size of the buffer memory. Such a selection is of no interest with a buffer of a size consistent with that of state-of-the-art buffers, which are so short that selecting an arbitrary reading position is of no use. .
  • the buffer memory is a cyclic buffer according to the aforementioned implementation
  • the multimedia module thus maintaining a start pointer of multimedia stream and an end pointer of multimedia stream.
  • the request for selecting an arbitrary read position then operates on a third pointer whose value is between the value of the start pointer of the multimedia stream and the value of the end pointer of the multimedia stream (when the values of these pointers are defined according to the aforementioned rating convention).
  • the broadcasting of multimedia streams since the cyclic buffer then operates from the address defined by this third pointer (when the selection is made) and not from the start pointer of the multimedia stream.
  • the multimedia module is arranged to trigger a delay when the interface INT receives a request to select a reading position.
  • the duration of the delay is of the same order of magnitude as the maximum duration of multimedia stream that can hold the buffer. This delay is interrupted by any new reception by the INT interface of another request to select a read position, reception which triggers again such a delay (as if there had not been previously).
  • the multimedia module is prohibited from overwriting a slippery zone (of the cyclic buffer) initially preceding the new selected position (and moving thereafter as the content of the cyclic buffer is issued, so as to immediately precede the current sample that is issued). This sliding area initially contains unencrypted data due to the selection of a new reading position.
  • this slippery area contains less and less data that has not been transmitted and more and more data that has already been sent (but which may need to be reissued according to the instructions of the user of the process. 'program). More specifically, the multimedia module seeks to fulfill the buffer at its maximum but without writing, during the delay, in the protected buffer zone.
  • the maximum size of this protected area is fixed at a duration corresponding to half of the maximum duration of multimedia stream included in the total cyclic buffer, ie for example five seconds. Any other time greater than one second but substantially less than the size of the cyclic buffer (for example 80% of the size of the cyclic buffer) may also be chosen.
  • the buffer is full (normal case during the transmission of a multimedia stream, unless there is a one-off problem or we reach the end of the total multimedia stream). If the user of the transmission process wishes to advance twenty seconds (for example if the current multimedia stream bores or shocks him and if he wishes to pass), the INT interface receives an instruction leading to twenty seconds advance . Instead of overwriting immediately (at least as far as the bit rate allows) the data corresponding to the twenty seconds not played, the delay allows to preserve them.
  • the multimedia module can not preserve thirty seconds since it only has the last twenty seconds (because of the advance of twenty seconds) and he can not write anything during ten seconds. Then for one minute and fifty seconds, he makes sure to preserve the last thirty seconds, and after this time he completely fills the cyclic buffer again without trying to preserve the thirty seconds preceding the current moment in the multimedia stream.
  • the mod ulemu ltim ed ia can immediately (to the extent that the bit rate allows it) to overwrite ten seconds of recorded multimedia stream corresponding to an earlier stream of more than thirty seconds at the current time, and then maintain a minimum of thirty seconds for the next two minutes.
  • a purpose of this function is, for example, to allow a user who has made an advance by or realizes that it has advanced more than it really wanted to have a guarantee of being able to go back instantly even in the event of a bad connection with the source of the multimedia stream, especially in the presence of a very irregular connection, which ensures a satisfactory average flow but with very frequent interruptions.
  • the multimedia stream of a multimedia stream transmission method is an MUS audio stream
  • the multimedia device MDEV comprises a digital analog converter DAC.
  • This embodiment allows a high quality audio broadcast (Hifi type).
  • a computer program comprises a series of instructions which, when executed by a processor, implement a method according to one of the preceding embodiments.
  • This computer program can be written in particular in C language, in C ++ language, and or in assembly language.
  • a non-transitory computer readable storage medium for example an HDD hard disk or a non-volatile memory, such as a flash memory or EEPROM
  • a computer program according to the fifth embodiment.
  • a multimedia stream transmission system comprises a PC computer and an MDEV multimedia device, the PC computer comprising an MP processor adapted to operate in user mode and in supervisor mode, the computer comprising a medium HDD storage device readable by the processor MP and storing a multimedia module MM, the multimedia module MM being arranged to be executed by the processor MP in supervisor mode.
  • the transmission system comprises an allocation circuit AL_C, in kernel space, of a buffer memory BUF arranged to contain at least ten seconds of multimedia stream.
  • the allocation circuit comprises a processor and a memory, said memory containing a computer program arranged to implement the allocation of the BUF buffer of at least ten seconds in kernel space.
  • the processor may be a central processor of the computer (which may be shared with other circuits) or a dedicated processor.
  • the memory can be a central memory of the computer (which can be shared with other circuits) or a dedicated memory. It can be a non-transitory memory.
  • the transmission system comprises an electronic reception circuit REC_C of a multimedia stream, arranged to receive said multimedia stream and store it in the buffer memory BUF.
  • the reception circuit comprises a processor and a memory, said memory containing a computer program arranged to receive multimedia signals and store it in said buffer memory BUF.
  • the processor may be a central processor of the computer (which may be shared with other circuits) or a dedicated processor.
  • the memory can be a central memory of the computer (which can be shared with other circuits) or a dedicated memory. It can be a non-transitory memory.
  • the transmission system comprises an electronic transmission circuit EM_C of a multimedia stream stored in the buffer BUF to the media device MDEV.
  • the transmission circuit comprises a processor and a memory, the memory containing a computer program arranged to transmit the multimedia stream stored in the buffer memory BUF to the media device MDEV.
  • the processor may be a central processor of the computer (which may be shared with other circuits) or a dedicated processor.
  • the memory can be a central memory of the computer (which can be shared with other circuits) or a dedicated memory. It can be a non-transitory memory.
  • a multimedia stream transmission system comprises an exclusive reservation electronic circuit RES_C of the multimedia device MDEV during the transmission of the multimedia stream.
  • the transmission circuit comprises a processor and a memory, said memory containing a computer program arranged to exclusively reserve the multimedia device M DEV while transmitting the multimedia stream.
  • the processor may be a central processor of the computer (which may be shared with other circuits) or a dedicated processor.
  • the memory can be a central memory of the computer (which can be shared with other circuits) or a dedicated memory. It can be a non-transitory memory.
  • the multimedia module MM of a multimedia stream transmission system comprises an interface I NT accessible from an MPL multimedia player executed by the MP processor in user mode, the transmission system comprising a sending electronic circuit SND_C request to select any read position in the buffer BUF MM multimedia module by the multimedia player MPL via said interface INT.
  • the sending circuit SND_C comprises a processor and a memory, said memory containing a computer program arranged to send a request to select any reading position in the buffer memory BUF to the multimedia module MM by the MPL media player via said INT interface.
  • the processor may be a central processor of the computer (which may be shared with other circuits) or a dedicated processor.
  • the memory can be a central memory of the computer (which can be shared with other circuits) or a dedicated memory. It can be a non-transitory memory.
  • a tenth embodiment relates to a multimedia stream transmission system according to one of the seventh to ninth embodiments, wherein the multimedia stream is an MUS audio stream and wherein the media device MDEV comprises a digital to analog converter. DAC.
  • the present invention is not limited to the embodiment described above by way of example; it extends to other variants.
  • the characteristics described with respect to the processes according to the invention are transposed to the systems corresponding to the invention, and vice versa.
  • Embodiments described for music pieces are transposed to other types of multimedia streams, including video streams, audio-video streams, augmented reality video streams, and even information streams controlling lighting devices (luminous projectors, lasers, etc.) or electromechanical devices (for example, fluxes driving robots or servomotors connected to elements of a scene in order to produce special effects in the context of a show ), in cases where very precise synchronization is required.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

L'invention se rapporte notamment à un procédé d'émission de flux multimédia (MUS, MOV) vers un périphérique multimédia (MDEV) d'un ordinateur (PC), l'ordinateur (PC) comprenant un processeur (MP) apte à fonctionner en mode utilisateur et en mode superviseur, l'ordinateur (PC) comprenant un support de stockage (HDD) lisible par le processeur (MP) et stockant un module multimédia (MM), le procédé d'émission comprenant une mise en œuvre, par le module multimédia (MM) exécuté par le processeur (MP) en mode superviseur, d'une allocation, d'une réception et d'une émission. L'invention concerne également un programme d'ordinateur, un dispositif de stockage et un système mettant en œuvre un tel procédé.

Description

AMÉLIORATION D'ÉMISSION DE FLUX MULTIMÉDIA
L'invention concerne l'amélioration de l'émission de flux multimédia, notamment des flux audio. L'accroissement de la puissance des micro- ord i nateu rs, des ord i nateu rs porta bles et des tablettes a perm is le développement du traitement en temps réel des enregistrements audio dont le but principal est de corriger les défauts dus à la technique de lecture et d'enregistrement sur les supports CD et SACD et d'améliorer la pureté du son par l'élimination des parasites dus à la numérisation elle-même et aux interférences introduites par les différents composants de la chaîne d'enregistrement et de reproduction.
Les sociétés qui ont créé des matériels et des logiciels pour cela, sont arrivées à obtenir un saut qualitatif dans la clarté et la pureté du son restitué.
Les améliorations complémentaires qui restent à apporter aux meilleurs matériels et logiciels sont relativement faibles tant que n'est pas apportée une solution au problème physique des parasites générés par les composants utilisés lors de la lecture du signal audio. Le niveau de parasites est lié au mode de fonctionnement de ces composants, et donc de celui du logiciel les contrôlant. Les solutions les plus avancées mises en œuvre jusqu'à ce jour pour les logiciels de lecture de musique dématérial isée sont réalisées au niveau applicatif du système d'exploitation utilisé dans ces systèmes.
Dans les solutions connues, seul le pilote du périphérique audio tourne dans le mode privilégié, le mode noyau (appelé également mode superviseur). La qualité d'émission de flux multimédia des solutions existantes est imparfaite.
L'invention vient améliorer la situation.
Un aspect de l'invention se rapporte à un procédé d'émission de flux multimédia vers un périphérique multimédia d'un ordinateur, l'ordinateur comprenant un processeur apte à fonctionner en mode utilisateur et en mode superviseur, l'ordinateur comprenant un support de stockage lisible par le processeu r et stockant u n mod u le m u lti méd ia , le procédé d'émission comprenant une mise en œuvre, par le module multimédia exécuté par le processeur en mode superviseur : /a/ d'une allocation, en espace noyau, d'une mémoire tampon agencée pour contenir au moins dix secondes de flux multimédia ;
/b/ d'une réception d'un flux multimédia, et de son stockage dans la mémoire tampon ;
Ici d'une émission d'un flux multimédia stocké dans la mémoire tampon vers le périphérique multimédia.
Ce procédé est avantageux notamment en ce qu'il permet d'améliorer la qualité du son et/ou de la vidéo compris dans un flux multimédia émis par un tel procédé. En mettant en œuvre l'exécution du module multimédia en mode superviseur, le procédé lui donne une très haute priorité pour la gestion en temps réel du flux multimédia. Par ailleurs, en lui allouant une mémoire tampon de taille non conventionnelle car très importante (au moins dix secondes) et en plaçant cette mémoire tampon dans l'espace noyau (accessible seulement en mode superviseur), le procédé permet d'assurer une plus grande continuité dans l'émission du flux multimédia, qui a moins de chances d'être interrompu (même pour des périodes très courtes), assurant ainsi également une plus grande qualité d'émission. De plus, le recours à l'espace noyau implique notamment (par rapport à un recours à l'espace utilisateur) une utilisation réduite de ressources mémoire et processeur, car il nécessite moins de recopies de zones mémoire et moins de changements de contexte du processeur, qui sont susceptibles de générer des interférences électriques et électromagnétiques lors de l'émission d'un flux multimédia.
Un autre aspect de l'invention se rapporte à un programme d'ordinateur comprenant une série d'instructions qui, lorsqu'elles sont exécutées par un processeur, mettent en œuvre un procédé selon un aspect de l'invention.
Un autre aspect de l'invention se rapporte à un support de stockage non transitoire lisible par ordinateur, comprenant un programme d'ordinateur selon un aspect de l'invention.
Un autre aspect de l'invention se rapporte à un système d'émission de flux multimédia, comprenant un ordinateur et un périphérique multimédia, l'ordinateur comprenant un processeur apte à fonctionner en mode utilisateur et en mode superviseur, l'ordinateur comprenant un support de stockage lisible par le processeur et stockant un module multimédia, le module multimédia étant agencé pour être exécuté par le processeur en mode superviseur, le système d'émission comprenant :
- un circu it d'allocation, en espace noyau , d'une mémoire tampon agencée pour contenir au moins dix secondes de flux multimédia ;
- un circuit de réception d'un flux multimédia, agencé pour recevoir ledit flux multimédia et le stocker dans la mémoire tampon ; - un circuit d'émission d'un flux multimédia stocké dans la mémoire tampon vers le périphérique multimédia.
Ce système est avantageux en ce qu'il est particulièrement adapté pour la mise en œuvre d'un procédé selon l'invention, et permet ainsi d'améliorer la qual ité du son et/ou de la vidéo compris dans un flux multimédia lors de l'émission de ce dernier.
D'autres aspects, buts et avantages de l'invention apparaîtront à la lecture de la description de quelques uns de ses modes de réalisation.
L'invention sera également mieux comprise à l'aide des dessins, sur lesquels :
la figure 1 illustre un système d'émission de flux multimédia selon un mode de réalisation;
la figure 2 illustre schématiquement le contenu d'une mémoire MEM selon un mode de réalisation;
- la figure 3 illustre un procédé d'émission de flux multimédia selon un mode de réalisation; la figure 4 illustre l'architecture d'un système selon un mode de réalisation;
la figure 5 illustre une procédure d'initialisation d'un procédé selon un mode de réalisation;
- la figure 6 illustre une lecture audio selon un mode de réalisation; la figure 7 illustre une mise en pause automatique selon un mode de réalisation;
la figure 8 illustre un procédé de détection et de traitement de fin d'émission d'un morceau de musique selon un mode de réalisation; - la figure 9 illustre un procédé d'arrêt d'émission d'un morceau de musique selon un mode de réalisation;
la figure 10 illustre une mémoire tampon en espace noyau, selon un mode de réalisation. Dans les figures décrites ci-dessous, les modes de réalisation se rapportent souvent à une flux audio, mais ces modes de réal isation s'appliquent également à d'autres types de flux.
La figure 1 illustre un ordinateur PC comprenant un disque dur HDD, un périphérique multimédia MDEV et une carte mère. Selon une variante, le périphérique multimédia MDEV peut être intégré à la carte mère. Le périphérique multimédia MDEV comprend un convertisseur numérique analogique DAC, par exemple pour convertir une donnée numérique issue d'un flux multimédia MUS (codant de la musique, qui peut être la partie audio d'un flux vidéo) en une tension électrique apte à commander un haut parleur (afin de restituer à l'aide du haut parleur la musique encodée dans le flux multimédia MUS, le cas échéant après amplification par un amplificateur). Les dispositifs de fixation du disque dur HDD et du périphérique multimédia ne sont pas représentés.
La carte mère est équipée d'un processeur MP (dont le système de refroidissement n'est pas représenté) et d'au moins une barrette de mémoire vive MEM (par exemple une barrette DIMM de DDR3 SDRAM). La carte mère est également équipée de cinq circuits AL_C, REC_C, EM_C, RES_C et SND_C. Ces circuits sont représentés sous forme de composants électroniques discrets distincts. Cependant, selon une mise en œuvre possible, les fonctions de ces cinq circuits sont remplies par un seul circuit assurant ces différentes fonctions. Selon une mise en œuvre possible les cinq circuits sont mis en œuvre par un circuit consistant en la réunion du processeur MP et de la mémoire MEM contenant des programmes spécifiques, d'une manière décrite plus précisément dans la suite de la description.
La carte mère comprend également un connecteur de stockage (SATA,
SCSI ou IDE par exemple), non représenté, pour connecter le disque dur HDD, et un connecteur de cartes d'extensions (par exemple un connecteur PCI, PCI Express ou AGP), non représenté, pour connecter notamment le périphérique multimédia MDEV.
Un bus (non représenté) relie les différents composants de la carte mère
(notamment le microprocesseur MP, la mémoire MEM, le périphérique multimédia MDEV, le disque dur HDD, et les différents circuits AL_C, REC_C, EM_C, RES_C et SND_C).
La figure 2 illustre schématiquement le contenu d'une mémoire MEM selon un mode de réalisation possible. La mémoire représentée est adressée en mode 32-bit (ce qu'illustre l'adresse initiale 0x00000000), mais peut bien sûr être adressée en 64-bit ou selon tout autre adressage approprié. La mémoire MEM contient, à partir d'une première adresse physique, un code exécutable correspondant à un lecteur multimédia MPL implémenté sous forme logicielle. La mémoire MEM contient, à partir d'une deuxième adresse physique, un code exécutable correspondant à un module multimédia MM. Ce module multimédia MM contient une interface INT, qui peut prendre la forme d'une API, à savoir un ensemble normalisé de classes, de méthodes ou de fonctions qui sert de façade par laquelle un logiciel offre des services à d'autres logiciels. La mémoire MEM contient, à partir d'une troisième adresse physique, un code exécutable correspondant à une mémoire tampon BUF. Le noyau étant normalement chargé avant les applications utilisateur, la mémoire nécessaire pour le module multimédia MM et son interface INT est en principe allouée avant la mémoire nécessaire pour le lecteur multimédia MPL. Il est donc possible que l'adresse physique du bloc mémoire contenant le module multimédia MM soit inférieure à l'adresse physique du bloc mémoire contenant le lecteur multimédia MPL (les positions relatives des blocs mémoire sur la figure 2, qui montrent une configuration inverse, ne sont qu'illustratives). Les trois plages mémoire stockant les informations précitées sont représentées chacune comme étant des plages continues. Cependant, en pratique elles ne le sont pas nécessairement. Ainsi, si la mémoire tampon est généralement allouée de façon continue, en un seul bloc (c'est-à-dire que toute adresse correspondant à une donnée de la mémoire tampon est immédiatement voisine d'au moins une autre adresse contenant une donnée de la mémoire tampon), ce n'est souvent pas le cas en ce qui concerne le module multimédia MM ou le lecteur multimédia MPL, qui peuvent chacun être chargés dans un ensemble de plusieurs blocs mémoire non contigus (espacés par des zones de mémoire non allouées, ou allouées à d'autres applications). Par ailleurs, la figure 2 représente des informations stockées en fonction de leurs adresses physiques. Les adresses virtuelles (qui sont habituellement distribuées par un MMU intégré au processeur et qui permettent de faire abstraction des adresses physiques) peuvent être différentes des adresses physiques (et le sont habituellement).
La figure 3 illustre un procédé d'émission de flux multimédia selon un mode de réalisation possible.
Lors d'une étape de réservation exclusive RES, un module multimédia MM effectue une réservation exclusive d'un périphérique multimédia MDEV. Une flèche est dirigée symboliquement du module multimédia MM vers le périphérique multimédia MDEV. Selon une m ise en œuvre possible, le périphérique multimédia reçoit ainsi une requête qu'il traite par exemple à l'aide d'un microcontrôleur intégré au périphérique multimédia. Mais la réservation exclusive n'atteint pas nécessairement le périphérique multimédia. Selon une mise en œuvre possible, la requête est par exemple dirigée vers un pilote de périphérique du périphérique multimédia, qui gère la réservation exclusive du périphérique multimédia et peut même ne pas informer le périphérique multimédia de sa réservation exclusive. A l'issue de l'émission d'un flux multimédia pris dans son ensemble (par exemple un film entier), le module multimédia peut procéder automatiquement à une libération du périphérique multimédia (afin de faire cesser la réservation exclusive).
Lors d'une étape AL d'allocation (pouvant suivre ou précéder l'étape RES de réservation exclusive), le module multimédia MM effectue une allocation d'une mémoire tampon BUF de grande taille en espace noyau.
Lors d'une étape REC de réception de flux multiméd ia, le module multimédia MM reçoit (sous forme de bloc de données) un extrait de flux multimédia (par exemple quelques secondes de musique MUS ou de vidéo MOV) de la part d'un lecteur multimédia MPL. Il enregistre cet extrait dans la mémoire tampon BUF. Il reçoit le cas échéant de tels extraits tant que la mémoire tampon n'est pas remplie.
Lors d'une étape EM d'émission de flux multimédia, le module multimédia MM émet (sous forme de bloc de données) un extrait de flux multimédia contenu dans la mémoire tampon BUF vers le périphérique multimédia MDEV. Dès que, la mémoire tampon ayant été remplie, une partie de son contenu a ainsi été émise, le module multimédia MM est agencé pour recevoir à nouveau des extraits de flux multimédia tant que la mémoire tampon n'est pas à nouveau remplie. Les parties de flux multimédia émises ne coïncident pas nécessairement exactement avec les parties de flux multimédia reçues. Il est par exemple possible de recevoir un flux multimédia par blocs de 3 kilooctets et de les émettre par blocs de 2 kilooctets. La taille des blocs reçus et émis n'est d'ailleurs pas nécessairement constante. Ainsi, bien que le flux reçu et le flux émis soient globalement identiques, leur découpage (en blocs de données pour la réception et en blocs de données pour l'émission) ne l'est pas nécessairement.
Par commodité d'écriture, il sera fait référence à des parties de flux de multimédia par l'expression "flux multimédia". En effet, une partie de flux multimédia reste un flux multimédia.
Lors d'une étape d'envoi SND, le lecteur multimédia (MPL) communique, via une interface (INT) du module multimédia MM, une demande de sélection d'une position de lecture quelconque dans la mémoire tampon (BUF). Malgré la grande taille de la mémoire tampon, il est ainsi possible d'effectuer par exemple une avance rapide sans qu'il ne soit nécessaire d'attendre la lecture de la mémoire tampon (à défaut il conviendrait d'attendre l'émission de la totalité du flux contenu dans la mémoire tampon) ni de charger de nouvelles données dans la mémoire tampon.
La figure 4 illustre l'arch itecture d'un système selon u n mode de réalisation. Une application audio MPL qui est chargée au niveau applicatif (en espace utilisateur) lit une grande quantité de données représentant un morceau de musique depuis une source de données audio (DVD, serveur distant, fichier local, etc.). Elle transfère alors ces données sous forme de petits paquets dans une mémoire tampon BUF d'un lecteur audio MM (un type particulier de module multimédia) qu i est chargé au niveau du noyau (en espace noyau). Elle opère ce transfert de données via une interface INT, qui lui sert également à envoyer des commandes au lecteur audio du noyau MM et à recevoir de sa part des notifications. Le lecteur audio du noyau MM transfère à son tour ces données à un pilote de périphérique DRV d'un périphérique audio MDEV. Le pilote de périphérique DRV est soit externe au lecteur audio du noyau MM soit directement intégré au lecteur audio du noyau MM. Les données sont alors transférées à une interface d'entrée/sortie IO, puis au périphérique audio MDEV.
La figure 5 illustre une procédure d'initialisation d'un procédé selon un mode de réalisation.
Une application audio MPL exécutée en espace utilisateur envoie une requête HQ_MOD à un lecteur aud io MM du noyau (exécuté en espace noyau) pour passer en mode de lecture audiophile (mode haute qualité). Si nécessaire, l'application audio MPL charge préalablement le lecteur audio du noyau MM en espace noyau.
Le lecteur audio du noyau MM envoie une requête S_RES de réservation exclusive d'un périphérique audio MDEV à un service audio du noyau. Cette requête conduit à une déconnexion du reste du système audio afin de neutraliser toute autre demande adressée au périphérique audio MDEV et ne venant pas du lecteur audio du noyau. Le service audio du noyau répond au lecteur audio du noyau MM en transmettant une notification S_RES_OK indiquant que la réservation exclusive a été correctement effectuée. Le lecteur audio du noyau MM envoie une requête REQ_F au périphérique audio MDEV afin qu'il lui communique les différents formats qu'il supporte (fréquence d'échantillonnage à 44, 1 kHz pour une qualité CD, à 96 kHz, nombre de canaux supportés, etc.). Ce dernier répond en envoyant les formats supportés dans un message SND_F. Le lecteur audio du noyau MM effectue alors une allocation AL d'une mémoire tampon BUF utilisée pour les données audio. Cette mémoire tampon est une mémoire tampon de grande taille (au moins dix secondes de données audio).
Le lecteur audio du noyau MM signale alors à l'application audio MPL, à l'aide d'un message HQ_MOD_OK, que le passage en mode audiophile a été correctement effectué.
La figure 6 illustre un procédé de lecture audio selon un mode de réalisation. Afin de diffuser un morceau de musique MUS, une application audio MPL commence par envoyer un message de configuration CONF1 à un lecteur audio du noyau MM. Le contenu de ce message peut être déterminé lors d'une procédure d'initialisation telle que représentée sur la figure 5. Le message de configuration CONF1 peut ainsi préciser par exemple que le morceau de musique qui sera transmis est échantillonné sur 24 bits, à une fréquence de 96 kHz, et qu'il est stéréophonique. Bien entendu, d'autres formats peuvent être employés. Le lecteur audio du noyau MM transmet à son tour un message de configuration CONF2 à un périphérique audio MDEV. Ce message CONF2 peut reprendre les éléments reçus dans le message CONF1 , et peut le cas échéant faire l'objet d'un traitement préalable. Une fois la configuration effectuée, le périphérique audio MDEV répond que celle-ci s'est bien déroulée par un message OK2 à destination du lecteur audio du noyau MM qui en informe à son tour l'application audio MPL à l'aide d'un message OK1 .
L'application audio MPL procède alors (étape LD) à un chargement de données audio dans la mémoire tampon BUF du lecteur audio du noyau MM. Dès que suffisamment de données ont été chargées (par exemple une quantité de données correspondant à au moins une seconde de musique), l'application audio MPL envoie un message RD1 au lecteur audio du noyau MM afin de lui demander de démarrer la lecture des données audio (c'est-à- dire leur émission à destination du périphérique audio MDEV en vue de sa diffusion sur des hauts parleurs). Le lecteur audio du noyau MM démarre la lecture en envoyant un message RD2 au périphérique audio MDEV.
Le procédé de lecture déclenche alors une boucle qui se répète en principe jusqu'à ce que la fin des données audio du morceau de musique à jouer soit atteinte (c'est-à-dire jusqu'à ce que tout le morceau de musique ait été traité). Cette boucle comprend l'envoi, par le périphérique audio MDEV au lecteur audio du noyau MM, d'une requête RQ_PK demandant l'envoi d'un paquet de données audio. Le lecteur audio répond en envoyant le paquet demandé à l'aide d'un message SND_PK, et incrémente (à une étape INC) la position de lecture dans la mémoire tampon du noyau BUF afin que la lecture suivante dans cette mémoire tampon du noyau corresponde au début du paquet suivant. Les paquets transmis sont construits à partir des données extraites de la mémoire tampon. Selon une mise en œuvre possible les paquets comprennent d'autres informations (telles qu'un en-tête indiquant par exemple une taille de paquet, un code de redondance cyclique, etc.). Selon une variante, aucune requête RQ_PK n'est envoyée, et le périphérique audio MDEV comprend un convertisseur numérique analogique DAC fonctionnant de façon synchrone. Le lecteur aud io du noyau MM est alors agencé pour envoyer les données audio sans requête, en décidant de lui même de la fréquence d'envoi, en fonction des paramètres du périphérique audio MDEV.
Périodiquement (par exemple toutes les secondes), le lecteur audio du noyau MM notifie l'application audio MPL de la position de lecture à l'aide d'un message NOT_POS. Alternativement (ou en complément, lorsque cela s'avère utile), l'application audio MPL peut elle-même accéder à cette information par exemple à l'aide de l'interface INT du lecteur audio du noyau (sans attendre de recevoir une notification).
L'application audio MPL, en fonction des notifications NOT_POS qu'elle a reçues et/ou des informations de flux qu'elle a lues directement (sans recourir à de telles notifications), remplit (étape CONT_LD) la mémoire tampon du noyau BUF (tant que le morceau de musique n'a pas été complètement diffusé).
La figure 7 illustre une mise en pause automatique en cas d'attente de données, selon un mode de réalisation.
Le lecteur audio du noyau MM est agencé pour détecter que la position de lecture par le lecteur audio du noyau MM dans la mémoire tampon du noyau BUF atteint une position correspondant à la fin des données audio chargées, mais qui n'est ni la position de la fin du morceau, ni celle de la fin de la mémoire tampon. Il opère par exemple cette détection par la détection d'un événement EMPTY_BUF (événement déclenché lorsque l'incrémentation INC de la position de lecture illustrée à la figure 6 atteint la position de fin des données audio dans la mémoire tampon), ou d'une interruption logicielle, ou par une boucle de test en continu effectuée par un thread séparé (un thread est parfois appelé une "tâche" ou un "fil d'exécution" en français).
Le lecteur audio du noyau envoie alors au périphérique audio MDEV une requête RQ_PSE de mise en pause (afin que le périphérique audio cesse de solliciter des paquets audio). Le périphérique audio MDEV répond par un message PSE_OK que la mise en pause s'est bien déroulée. Le lecteur audio du noyau MM notifie alors l'application audio MPL, par une notification NOT_PSE, que le périphérique audio MDEV s'est mis en pause faute de données. Selon une mise en œuvre alternative, au lieu d'envoyer une requête RQ_PSE de mise en pause au périphérique audio MDEV, le lecteur audio du noyau MM lui envoie des paquets de "silence" (c'est-à-dire des paquets contenant des échantillons constants représentant un signal nul, correspondant à du silence) jusqu'à ce que la mémoire tampon BUF ait à nouveau suffisamment de données. Cette alternative présente l'avantage d'une interopérabilité accrue avec tout type de périphérique audio (le périphérique audio ne se rendant pas compte de la mise en pause, qui est simulée).
Le lecteur audio du noyau continue pendant ce temps de vérifier le contenu de la mémoire tampon du noyau par un mécanisme analogue à celui qui lui permet de détecter qu'il n'y a plus de données dans cette mémoire tampon du noyau. Dès qu'une quantité suffisante de données est détectée, par exemple à l'aide d'un événement BUF_FILL, le lecteur du noyau transmet un message RES_RD au périphérique audio MDEV afin que celui-ci reprenne la lecture. Le péri phériq ue aud io M DEV répond à l'a ide d'u n message RES_RD_OK qu'il a bien repris la lecture, ce que le lecteur audio du noyau MM notifie à l'application audio MPL à l'aide d'une notification NOT_RD.
La figure 8 illustre un procédé de détection et de traitement de fin d'émission d'un morceau de musique selon un mode de réalisation.
Un lecteur audio du noyau MM est agencé pour détecter que la position de lecture par le lecteur audio du noyau MM dans une mémoire tampon du noyau BUF atteint une position correspondant à la fin de cette mémoire tampon, ou à la fin d'un morceau joué. Il opère par exemple cette détection par la détection d'un événement REACH_END, par une interruption logicielle, ou par une boucle de test en continu effectuée par un thread séparé.
Le lecteur audio du noyau envoie alors à une application audio MPL une notification NOT_END de fin de lecture de la mémoire tampon du noyau ou de fin de lecture du morceau L'application audio MPL vérifie alors (étape TST_MORE_DAT) si des données audio sont présentes après cette position, ou dans une mémoire tampon suivante (lorsqu'il y a plusieurs mémoires tampon). Si c'est le cas, elle continue la lecture à partir de la mémoire tampon courante ou suivante, selon le cas (étape CONT RD). Sinon (étape NO_MORE_DAT), le lecteur audio du noyau envoie au périphérique audio MDEV une requête PSE de mise en pause (afin que le périphérique audio cesse de solliciter des paquets audio). Le périphérique audio MDEV répond par un message OK_PSE que la mise en pause s'est bien déroulée. Le lecteur audio du noyau MM notifie alors l'application audio MPL, par une notification NOTIF_P, que le périphérique audio MDEV s'est mis en pause faute de données. Selon une mise en œuvre alternative, au lieu d'envoyer une requête PSE de m ise en pause au périphérique audio MDEV, le lecteur audio du noyau MM lu i envoie des paquets de silence, de la manière précédemment indiquée. Ceci permet notamment de passer automatiquement de la lecture de la fin d'un morceau à la lecture du début d'un morceau suivant.
La figure 9 illustre un procédé d'arrêt d'émission d'un morceau de musique selon un mode de réalisation. Une application audio MPL requiert d'un lecteur audio du noyau MM qu'il arrête la lecture d'un morceau de musique par un périphérique audio MDEV, à l'aide d'une requête RQ_STP1 . Le lecteur audio du noyau MM requiert du périphérique audio MDEV qu'il arrête la lecture du morceau de musique, à l'aide d'une requête RQ_STP2. Le périphérique audio MDEV répond au lecteur audio du noyau MM qu'il a arrêté la lecture à l'aide d'un message STP2_OK. Le lecteur audio du noyau MM notifie l'application audio MPL qu'il a arrêté la lecture à l'aide d'un message STP1_OK.
L'application audio MPL demande alors au lecteur audio MM, à l'aide d'un message RQ_NM, qu'il revienne en mode normal (non audiophile).
Le lecteur audio du noyau MM demande à un service audio du noyau, à l'aide d'une requête RQ_RECONF1 , une reconfiguration du périphérique audio MDEV. Le service audio du noyau demande au périphérique audio MDEV, à l'aide d'une requête RQ_RECONF2, la reconfiguration requise. Le périphérique audio MDEV répond au service audio du noyau, à l'aide d'une notification RECONF2_OK qu'il s'est bien reconfiguré. Le service audio du noyau notifie le lecteur audio du noyau MM, à l'aide d'une notification RECONF1_OK que le périphérique audio MDEV est bien reconfiguré (et prêt à être utilisé de nouveau).
Le lecteur audio du noyau MM demande alors au service audio du noyau, à l'aide d'une requête RQ_FR, qu'il fasse cesser la réservation exclusive du périphérique audio MDEV. Le service audio du noyau répond à l'aide d'une notification FR_OK qu'il a bien fait cesser cette réservation exclusive. Le lecteur audio du noyau MM en notifie l'application audio MPL.
Le lecteur audio du noyau MM peut alors être déchargé du noyau, et il peut auparavant libérer la mémoire tampon en mode noyau (étape UNLD). Le contrôle du périphérique audio MDEV peut alors être rendu au système d'exploitation.
La figure 10 illustre une mémoire tampon en espace noyau, selon un mode de réalisation. La mémoire tampon illustrée comprend des données audio en cours de lecture. La position de lecture courante est identifiée par un pointeur RD_POS. La fin des données audio chargées dans la mémoire tampon est identifiée par un pointeur POS_END_LD_AU. La position de fin du morceau (à supposer qu'elle se situe dans la mémoire tampon) est identifiée par un pointeur POS_END_AU. La position de fin de mémoire tampon est identifiée par un pointeur POS_END_BUF.
Un premier mode de réalisation se rapporte à un procédé d'émission de flux multimédia (tel qu'un flux de musique MUS, ou de vidéo MOV) via un périphérique multimédia MDEV d'un ordinateur PC. Selon une mise en œuvre possible, le périphérique multimédia, qui est un dispositif matériel (par exemple une carte son, une carte graphique, ou encore la combinaison des deux), fait partie intégrante de l'ordinateur. Selon une mise en œuvre alternative, le périphérique multimédia est extérieur à l'ordinateur et lui est simplement connecté (par lien filaire ou sans fil).
L'ordinateur est par exemple un ordinateur personnel (portable ou de bureau), mais il peut également s'agir par exemple d'un téléphone portable, d'une tablette, d'un lecteur MP3, d'une montre connectée, d'un serveur ou encore d'un lecteur réseau. Selon une mise en œuvre possible, un tel lecteur réseau constitue tout ou partie d'un boîtier intégré contenant à la fois une partie ordinateur (apte à lire un flux multimédia depuis un stockage interne et/ou depuis un réseau informatique) et une partie Hifi apte à restituer un flux multimédia d'une manière perceptible par une oreille humaine.
L'ordinateur comprend au moins un processeur MP apte à fonctionner en mode utilisateur et en mode superviseur (il peut s'agir d'un processeur multicœur ou monocœur). En mode utilisateur, le processeur vérifie de manière assez stricte (sous le contrôle du système d'exploitation) l'accès au ressources (mémoire, périphériques, etc.), ce qui permet d'éviter notamment qu'un logiciel (exécuté dans ce mode utilisateur) accapare des ressources, provoque un plantage de l'ordinateur, ou obtienne des accès à des informations confidentielles auxquelles il n'est pas censé accéder. Ce mode utilisateur est donc le mode par défaut utilisé par les logiciels. Cependant, le fait que le mode utilisateur soit sujet à des contrôles accrus signifie que ce mode utilisateur est plus lent et moins réactif. Lorsque de la mémoire est allouée par un logiciel exécuté en mode utilisateur, elle est allouée dans l'espace utilisateur (un espace dans lequel la mémoire des autres logiciels et du système d'exploitation n'est pas accessible). Lorsque de la mémoire est allouée en mode superviseur, elle est allouée dans l'espace noyau, qui est un espace dans lequel toutes les ressources sont visibles. Dans l'espace noyau, il est ainsi possible de consulter les portions de mémoire physique utilisées par tous les logiciels exécutés par l'ordinateur, et même d'y apporter des modifications (effacer des informations, les remplacer, etc.), ce qu i peut s'avérer très dangereux. En mode superviseur (dit également mode noyau), le processeur a ainsi un accès quasiment illimité aux ressources de l'ordinateur, notamment à sa mémoire. Le mode noyau est donc en principe réservé au noyau du système d'exploitation, noyau qui gère des fonctions bas niveau (pilotes de périphériques, accès au matériel, etc.).
Selon le premier mode de réalisation, l'ordinateur comprend un support de stockage (tel qu'un disque dur magnétique HDD, ou encore un SSD, parfois appelé disque électronique, composé de mémoire telle que de la mémoire flash, ou toute autre type de support de stockage) lisible par le processeur et stockant un module multimédia MM. Le module multimédia MM est par exemple le résultat de la compilation d'un programme écrit dans un langage assurant des performances assez élevées (par contraste avec certains langages interprétés par exemple), tel que le langage C ou C++. Le module multimédia peut même être le résultat de l'assemblage d'un logiciel écrit directement en assembleur, ce qui peut permettre une optimisation supplémentaire des performances. Le module multimédia peut aussi être mixte, au sens où il peut résulter de la compilation d'un programme écrit pour partie dans un langage tel que le langage C mais dont certaines parties (critiques du point de vue de la performance) sont écrites directement en assembleur.
Le module multimédia MM est conçu pour être exécuté par le processeur
MP en mode superviseur. Ce module multimédia est par exemple intégré au noyau d'un système d'exploitation installé sur l'ordinateur, qui peut être un système d'exploitation conventionnel, par exemple du type Microsoft Windows, Linux, OS X, Android, iOS, Windows Phone, BlackBerry, Symbian, etc. Ce module multimédia peut par exemple être intégré à un pilote de périphérique, notamment à un pilote de périphérique gérant le périphérique multimédia MDEV. Ce module multimédia peut alternativement être installé au même niveau qu'un tel pilote de périphérique (sans y être intégré). Le module multimédia peut également être intégré dans une extension du noyau chargée dynamiquement (à la demande), ou être intégré directement à l'intérieur d'un noyau monolithique (il est ainsi possible de compiler un noyau spécialement pour cet usage). L'exécution du module multimédia en mode superviseur lui confère des performances accrues. Il peut en particulier jouir d'une priorité sur d'autres modules exécutés en parallèle mais en mode utilisateur. L'exécution en mode superviseur permet d'améliorer la vitesse de réponse à des sollicitations du périphérique multimédia (qui peut notamment émettre des requêtes pour recevoir la suite d'un flux multimédia qu'il est en train de jouer). Ceci améliore la précision temporelle du signal porté par le flux multimédia, grâce à la priorité du module multimédia sur tous les modules exécutés en mode utilisateur, d'autant plus que l'exécution du processus de réponse ne nécessite pas dans ce cas d'appeler des routines présentes en mode utilisateur. L'activité nécessaire à l'émission du flux multimédia en mode superviseur étant inférieure à l'activité nécessaire à l'ém ission du flux multimédia en mode utilisateur, elle permet de réduire les parasites (notamment électromagnétiques) liés à cette activité.
Le procédé d'émission comprend une mise en œuvre, par le module multimédia, d'une allocation, en espace noyau, d'une (ou, alternativement, de plusieurs) mémoire(s) tampon BUF agencée(s) pour contenir (collectivement, s'il y en a plusieurs) au moins dix secondes de flux multimédia. Cette mémoire tampon, en plus de se situer en espace noyau, a ainsi une taille beaucoup plus élevée que dans l'art antérieur ce qui permet d'assurer une continuité lors de rémission d'un flux multimédia. Le flux multimédia émis par le module multimédia vers le périphérique multimédia prend la forme de données, qui sont, avant d'atteindre le périphérique multimédia, susceptibles de transiter par plusieurs éléments intermédiaires, notamment par un pilote de périphérique du périphérique multimédia et par des modules d'un noyau d'un système d'exploitation de l'ordinateur. De nouvelles données sont régulièrement stockées dans la mémoire tampon (susceptible d'être utilisée par de tels modules du noyau) afin d'assurer la continuité de l'émission du flux multimédia. L'utilisation d'une taille non conventionnelle (correspondant à au moins dix secondes de fl ux multimédia) pour cette mémoire tampon permet notamment de réaliser des transferts de données (depuis une source de flux multimédia, telle qu'un lecteur multimédia, vers le module multimédia) de taille unitaire bien plus importante, et donc de réduire fortement le nombre de ces transferts pendant l'émission des données multimédia vers le périphérique multimédia. Cela limite donc fortement l'activité supplémentaire générée pour requérir de nouvelles données et les transmettre. Ceci réduit corrélativement les interférences électromagnétiques générées par cette activité supplémentaire. La grande taille de la mémoire tampon est ainsi avantageuse en ce qu'une perturbation quelconque empêchant temporairement l'obtention de données depuis une source multimédia peut être compensée pendant une durée pouvant aller jusqu'à dix secondes au minimum.
Selon une mise en œuvre possible, le seuil de dix secondes n'est pas strict et doit s'entendre comme signifiant : environ dix secondes (à titre d'exemple, neuf secondes peuvent suffire). La durée des mémoires tampon de l'art antérieur est inférieure à une seconde, et celle de la mémoire tampon selon l'invention s'en distingue en ce qu'elle est beaucoup plus longue (au minimum dix fois plus longue).
Une telle durée (au minimum une dizaine de secondes) paraît suffisante pour contrer les effets sur l'émission d'un flux multimédia de phénomènes susceptibles de ralentir ou perturber fortement mais très temporairement l'ordinateur. De tels phénomènes peuvent être liés par exemple à un manque temporaire de mémoire vive. Dans une telle hypothèse, il est courant de recourir à une mémoire virtuelle complétant la mémoire vive insuffisante. Cette mémoire virtuelle s'appuie sur un support de stockage de masse, beaucoup plus lent que la mémoire vive mais de capacité beaucoup plus importante (typiquement, un disque dur). Si une portion de flux multimédia à émettre se trouve en mémoire virtuelle, il est nécessaire pour y accéder d'effectuer une opération dite de "swap mémoire" (le mot "swap" signifiant "échange" en anglais) au cours de laquelle les données représentant la portion de flux multimédia stockées en mémoire de masse (par exemple sur un disque dur) sont chargées en mémoire vive en remplacement de données qui s'avèrent ne pas avoir été utilisées depuis longtemps. Cette opération de "swap mémoire", qui peut être longue, peut alors provoquer (dans le cadre des solutions antérieures) une coupure dans l'émission du flux multimédia. Le recours à une mémoire tampon de taille importante permet d'absorber des opérations de "swap mémoire" ponctuellement requises sans interruption dans l'émission du flux multimédia. De tels phénomènes peuvent également être liés à des phases préparatoires à l'exécution automatique de tâches de fond. Ils peuvent être dus notamment à un logiciel antivirus, à un log iciel d'arch ivage automatique de données (copiant les données nouvellement inscrites sur un disque dur de l'ordinateur vers un support d'archivage), à une maintenance automatique de disque dur (telle qu'une défragmentation), à une recherche automatique de mises à jour de logiciels installés sur l'ordinateur, etc. Ces phases préparatoires, même si elles ne conduisent pas à dépasser les capacités de la mémoire vive, peuvent conduire à solliciter le processeur de manière importante. Le fait d'opérer en mode superviseur permet alors de garantir une disponibilité du processeur supérieure à celle qui serait accordée à un module exécuté en mode utilisateur, et de réduire ainsi la probabilité que rémission du flux multimédia soit affectée. Par ailleurs, même si la source du flux multimédia (qui peut le cas échéant mettre en œuvre des modules exécutés en mode utilisateur) est temporairement tarie par une telle phase préparatoire, la mémoire tampon de taille importante permet de compenser un tel tarissement pendant au moins dix secondes.
Le procédé d'émission comprend une mise en œuvre, par le module multimédia, d'une réception d'un flux multimédia (par exemple depuis un serveur distant, via un réseau, ou encore depuis un stockage local tel qu'un disque dur local ou une clé USB), et de son stockage dans la mémoire tampon. Ce flux multimédia est entendu comme une portion de flux multimédia correspondant aux capacités de la mémoire tampon. Ainsi, il est possible de conserver en continu au moins dix secondes de flux multimédia, et au fur et à mesure que le contenu de la mémoire tampon est émis, il est remplacé par une portion suivante de flux multimédia, reçue de manière analogue à la réception précitée, de manière à remplir en permanence autant que possible la mémoire tampon.
Le procédé d'émission comprend une mise en œuvre, par le module multimédia, d'une émission d'un flux multimédia stocké dans la mémoire tampon BUF vers le périphérique multimédia. Selon une mise en œuvre possible, cette émission s'opère par transmission de petits paquets de flux multimédia issus de la mémoire tampon BUF, la taille desdits paquets étant fixée par périphérique multimédia MDEV.
Le flux multimédia peut provenir de toute origine. Il peut provenir d'un fichier stocké dans l'ordinateur, mais il peut également provenir d'une entité externe, par exemple d'un serveur distant (par exemple à l'aide d'une technique dite de "streaming", parfois appelée en français flux direct, diffusion en flux, lecture en continu, lecture en transit ou encore diffusion en mode continu).
Selon un deuxième mode de réalisation, un procédé d'émission de flux multimédia selon le premier mode de réalisation comprend une m ise en œuvre, par le module multimédia MM, d'une réservation exclusive RES du périphérique multimédia MDEV pendant l'émission du flux multimédia. Ainsi, aucun autre logiciel n'est susceptible d'interférer avec le module multimédia MM lorsque (tant que) ce dernier émet un flux à destination du périphérique multimédia MDEV en sollicitant un accès concurrent à ce même périphérique multimédia. Par exemple, dans l'hypothèse où le périphérique multimédia est une carte son, la réception d'un email dans un log iciel de messagerie électronique ne sera pas susceptible de déclencher un son intempestif de nature non seulement à se superposer avec (ou à interrompre) l'émission du flux multimédia, mais aussi de nature à perturber une telle émission (par exemple en générant des parasites liés au fait que le logiciel de messagerie tente d'accéder au même périphérique multimédia et consomme ainsi des ressources de ce périphérique multimédia). Selon une mise en œuvre possible, l'émission de flux multimédia est continue (sauf intervention d'un utilisateur requérant par exemple une pause), et la réservation reste exclusive jusqu'à la fin de l'émission de la totalité du flux multimédia considéré (par exemple jusqu'à la fin de la diffusion complète d'un film entier). Ainsi, la réservation exclusive peut s'opérer comme préalable à la diffusion du flux multimédia entier (juste avant le début d'un film par exemple), et subsister pendant tout le film (qui comprend de nombreuses réceptions de parties de flux multimédias et émission de parties de flux multimédias), sans qu'il ne soit nécessaire d'effectuer à nouveau un réservation exclusive à chaque réception d'une nouvelle partie de flux multimédia (la réservation exclusive initiale perdure).
Selon une mise en œuvre possible, la réservation exclusive s'opère au niveau du noyau d'un système d'exploitation installé sur l'ordinateur. Cette mise en œuvre comprend le remplacement d'un pilote du périphérique multimédia ou d'un module du noyau contrôlant le périphérique multimédia par un nouveau pilote de périphérique (respectivement un nouveau module du noyau) intégrant une fonction permettant de refuser toute connexion d'une application autre qu'une source multimédia déterminée. La source multimédia est par exemple un lecteur multimédia (prenant la forme d'un module applicatif), seul ce module applicatif étant autorisé par le nouveau pilote de périphérique (respectivement driver). Selon une mise en œuvre possible, la fonction prend en paramètre d'entrée un identifiant de la source multimédia ainsi qu'un bit dont une valeur indique qu'une réservation exclusive est requise, et l'autre valeur indique que la réservation exclusive n'est plus requise. Selon une mise en œuvre possible, cette fonction est sécurisée, par exemple en prédéfinissant la ou les sources multimédia habilitée(s) à requérir une réservation exclusive et en interdisant à toute application autre que figurant dans la liste d'applications autorisées ainsi prédéfinies d'effectuer une réservation exclusive. Selon une m ise en œuvre possible, il n'y a qu'une source autorisée, et la fonction ne prend pas en paramètre d'entrée l'identifiant de cette source. Selon une mise en œuvre possible, l'ensemble (ou alternativement une partie) des fonctions du pilote de périphériques (respectivement du module du noyau) se rapportant à l'ém ission de flux multimédia est modifié pour que ces fonctions renvoient un code d'erreur lorsqu'une réservation exclusive a été effectuée et lorsqu'elle identifient que le module applicatif appelant n'est pas celui pour lequel une réservation exclusive a été demandée. Selon une autre mise en œuvre possible, la réservation exclusive s'opère au niveau du noyau d'un système d'exploitation installé sur l'ordinateur, de la façon suivante. Un module d'interface qui réalise l'interface entre des modules applicatifs et des pilotes de périphérique multimédia au niveau du noyau est remplacé par un nouveau module d'interface intégrant une fonction permettant de refuser toute connexion d'une application autre qu'une source multimédia déterminée, d'une manière similaire à celle indiquée au paragraphe précédent. Selon une autre mise en œuvre possible, la réservation exclusive s'opère au niveau applicatif d'un système d'exploitation installé sur l'ordinateur. Le système d'exploitation fournit une fonction pour réserver un accès exclusif au périphérique multimédia. Une source multimédia telle que le lecteur multimédia applicatif appelle cette fonction du système d'exploitation afin d'opérer une réservation exclusive.
Selon une mise en œuvre possible, la mémoire tampon est une mémoire tampon cyclique. Le module multimédia maintient un pointeur de début de flux multimédia (pointant sur une partie de flux multimédia contenue dans la mémoire tampon cyclique et sur le point d'être émise) et un pointeur de fin de flux multimédia (pouvant être identique au pointeur de début de fl ux multimédia si la mémoire tampon cyclique est pleine).
Selon une convention de notation possible, on attribue la valeur zéro au pointeur de début de flux multimédia (indépendamment de l'adresse mémoire correspondant au début de flux multimédia). Par exemple, considérons une mémoire tampon cyclique de 1764000 octets (soit 0x1AEAA0 octets en notation hexadécimale), occupant une zone mémoire comprise de l'adresse 0x03000000 à l'adresse 0x031AEA9F. Une telle mémoire tampon cyclique peut ainsi contenir dix secondes de flux audio stéréo échantillonné à 16 bits par canal, à une fréquence de 44,1 kHz. Le début de flux multimédia peut ainsi se situer à n' im porte q uel le ad resse comprise entre 0x03000000 et 0x031AEA9F (par exemple, l'adresse 0x0305ABE6). Mais quelle que soit l'adresse @DFM de début de flux multimédia, on attribue conventionnellement la valeur zéro au pointeur sur ce début de flux multimédia. La valeur associée à tout autre pointeur pointant sur une adresse @Q quelconque située à l'intérieur de la mémoire tampon cyclique est alors définie conventionnellement comme étant égale à (@Q + SZBUF - @DFM) Mod SZBUF, SZBUF désignant la taille de la mémoire tampon (par exemple 1764000 dans l'exemple ci- dessus). Si les deux pointeurs de début et de fin de flux multimédia ont des valeurs différentes, le module multimédia essaye de recevoir davantage de flux multimédia dans la mémoire tampon cyclique jusqu'à ce que les deux pointeurs aient une valeur identique. B ien q u e l 'ad resse mémoire correspondant au pointeur de début de flux multimédia ne cesse de changer au fur et à mesure de l'émission du contenu de la mémoire tampon, et ce de manière cyclique, on peut selon cette convention de notation lui attribuer en permanence la valeur de référence zéro.
Bien entendu, toute autre convention de notation est possible.
Selon un troisième mode de réalisation, le module multimédia MM d'un procédé d'émission de flux multimédia selon le premier ou deuxième mode de réalisation comprend u ne interface I NT accessi ble depu is u n lecteu r multimédia MPL exécuté par le processeur MP en mode utilisateur, le procédé d'émission comprenant un envoi SND au module multiméd ia MM , par le lecteur multimédia MPL, via ladite interface INT, d'une demande de sélection d'une position de lecture quelconque dans la mémoire tampon BUF. Ainsi, le module multimédia permet de sélectionner une position de lecture à une position arbitraire dans la mémoire tampon, et non simplement une position prédéfinie telle que le début de la mémoire tampon. Ceci est particulièrement avantageux compte-tenu de la taille de la mémoire tampon. Une telle sélection ne présente pas d'intérêt avec une mémoire tampon d'une taille conforme à celle des mémoires tampon de l'état de l'art, qui sont si courtes que sélectionner une position de lecture arbitraire n'a pas d'utilité.
Selon une autre mise en œuvre, la mémoire tampon est une mémoire tampon cyclique selon la mise en œuvre précitée, le module multimédia maintenant donc un pointeur de début de flux multimédia et un pointeur de fin de flux multimédia. La demande de sélection d'une position de lecture quelconque opère alors sur un troisième pointeur dont la valeur est comprise entre la valeur du pointeur de début de flux multimédia et la valeur du pointeur de fin de flux multimédia (lorsque les valeurs de ces pointeurs sont définies selon la convention de notation précitée). L'émission de flux multimédia depuis la mémoire tampon cyclique s'opère alors à partir de l'adresse définie par ce troisième pointeur (lorsque la sélection est opérée) et non à partir du pointeur de début de flux multimédia. Ainsi, il est possible d'effectuer des avances rapides puis des reculs rapides sans avoir à être en mesure de recevoir davantage de flux multimédia, tant que ces avances et reculs rapides se cantonnent au contenu de la mémoire tampon cyclique. Sans ce troisième pointeur mettant en œuvre la sélection d'une position de lecture quelconque, une avance rapide suivie d'un recul rapide impliquerait, à défaut de fonctions particulières, un nouveau téléchargement. En effet, une fois le pointeur de début de flux multimédia déplacé pour une avance rapide, il n'est pas possible de le déplacer dans l'autre sens afin d'effectuer un recul rapide si l'on n'est pas en mesure de savoir quel contenu se trouve avant le pointeur de début de flux multimédia (le contenu précédent a pu être écrasé par la réception d'un autre contenu).
Selon une mise en œuvre possible, le module multimédia est agencé pour déclencher une temporisation à réception par l'interface INT d'une demande de sélection d'une position de lecture. Selon une mise en œuvre possible, la durée de la temporisation est du même ordre de grandeur que la durée maximale de flux multimédia que peut contenir la mémoire tampon . Cette temporisation est interrompue par toute nouvelle réception par l'interface INT d'une autre demande de sélection d'une position de lecture, réception qui déclenche à nouveau une telle temporisation (comme s'il n'y en avait pas eu précédemment). Durant la temporisation, le module multimédia s'interdit d'écraser une zone glissante (de la mémoire tampon cyclique) précédant initialement la nouvelle position sélectionnée (et se déplaçant par la suite au fur et à mesure que le contenu de la mémoire tampon cyclique est émis, de façon à précéder immédiatement l'échantillon courant qui est émis). Cette zone glissante contient initialement des données non émises du fait de la sélection d'une nouvelle position de lecture. Par la su ite, au cours de la temporisation, cette zone glissante contient de moins en moins de données non émises et de plus en plus de données déjà émises (mais qui pourraient devoir être réémises, selon les instructions de l'utilisateur du procédé d'émission). Plus précisément, le module multimédia cherche à remplir la mémoire tampon à son maximum mais sans écrire, pendant la temporisation, dans la zone de mémoire tampon ainsi protégée. Selon une mise en œuvre, la taille maximale de cette zone protégée est fixée à une durée correspondant à la moitié de la durée maximale de flux multimédia comprise dans la mémoire tampon cyclique totale, soit par exemple cinq secondes. Toute autre durée supérieure à une seconde mais substantiellement inférieure à la taille de la mémoire tampon cyclique (par exemple 80% de la taille de la mémoire tampon cyclique) peut également être choisie.
Par exemple, considérons une mémoire tampon cyclique d'une minute, une durée de temporisation de deux minutes, et une taille maximale de zone à préserver de trente secondes. Supposons que la mémoire tampon est pleine (cas normal durant l'émission d'un flux multimédia, à moins qu'il y ait un problème ponctuel ou que l'on atteigne la fin du flux multimédia total). Si l'utilisateur du procédé d'émission souhaite avancer de vingt secondes (par exemple si le flux multimédia courant l'ennuie ou le choque et s'il souhaite le passer), l'interface INT reçoit une instruction aboutissant à avancer de vingt secondes. Au lieu d'écraser immédiatement (du moins dans la mesure ou le débit le permet) les données correspondant au vingt secondes non jouées, la temporisation permet de les préserver. Plus précisément, au tout début de l'avance rapide, le module multimédia ne peut pas préserver trente secondes puisqu'il ne dispose que des vingt dernières secondes (en raison de l'avance de vingt secondes) et il ne peut donc rien écrire pendant dix secondes. Puis pendant une minute et cinquante secondes, il s'assure de préserver les trente dernières secondes, et passé ce délai il remplit à nouveau complètement la mémoire tampon cyclique sans chercher à préserver les trente secondes précédant l'instant présent dans le flux multimédia. Da n s l a m êm e configuration, si l'utilisateur souhaite cette fois-ci avancer de quarante secondes au lieu de vingt secondes, l e mod u l e m u ltim éd ia peut immédiatement (dans la mesure où le débit le permet) écraser dix secondes de flux multimédia enregistré correspondant à un flux antérieur de plus de trente secondes à l'instant courant, et maintenir ensuite un minimum de trente secondes pendant les deux minutes suivantes. Une finalité de cette fonction est par exemple de permettre à un utilisateur qui a effectué une avance par mégarde ou qui se rend compte qu'il a avancé davantage qu'il ne le souhaitait réellement d'avoir une garantie de pouvoir revenir en arrière instantanément même en cas de mauvaise liaison avec la source du flux multimédia, en particulier en présence d'une liaison très irrégulière, qui assure un débit moyen satisfaisant mais avec des interruptions très fréquentes.
Selon un quatrième mode de réalisation, le flux multimédia d'un procédé d'émission de flux multimédia selon l'un des modes de réalisation précédents est un flux audio MUS, et le périphérique multimédia MDEV comprend un convertisseur numérique analogique DAC. Ce mode de réalisation permet une émission audio de haute qualité (de type Hifi).
Selon un cinquième mode de réalisation, un programme d'ordinateur comprend une série d'instructions qui, lorsqu'elles sont exécutées par un processeur, mettent en œuvre un procédé selon l'un des modes de réalisation précédents. Ce programme d'ordinateur peut être écrit notamment en langage C, en langage C++, et ou en langage assembleur.
Selon un sixième mode de réalisation, un support de stockage non transitoire lisible par ordinateur (par exemple un disque dur HDD ou une mémoire non volatile, telle qu'une mémoire Flash ou EEPROM) comprend un programme d'ordinateur selon le cinquième mode de réalisation.
Selon un septième mode de réalisation, un système d'émission de flux multimédia comprend un ordinateur PC et un périphérique multimédia MDEV, l'ordinateur PC comprenant un processeur MP apte à fonctionner en mode utilisateur et en mode superviseur, l'ordinateur comprenant un support de stockage HDD lisible par le processeur MP et stockant un module multimédia MM, le module multimédia MM étant agencé pour être exécuté par le processeur MP en mode superviseur.
Le système d'émission comprend un circuit électronique d'allocation AL_C, en espace noyau, d'une mémoire tampon BUF agencée pour contenir au moins dix secondes de flux multimédia. Selon une mise en œuvre possible, le circuit d'allocation comprend un processeur et une mémoire, ladite mémoire contenant un programme d'ordinateur agencé pou r mettre en œuvre l'allocation de la mémoire tampon BUF d'au moins dix secondes en espace noyau. Le processeur peut être un processeur central de l'ordinateur (qui peut être partagé avec d'autres circuits) ou un processeur dédié. La mémoire peut être une mémoire centrale de l'ordinateur (qui peut être partagée avec d'autres circuits) ou une mémoire dédiée. Il peut s'agir d'une mémoire non transitoire.
Le système d'émission comprend un circuit électronique de réception REC_C d'un flux multimédia, agencé pour recevoir ledit flux multimédia et le stocker dans la mémoire tampon BUF. Selon une mise en œuvre possible, le circuit de réception comprend un processeur et une mémoire, ladite mémoire contenant un programme d'ordinateur agencé pour recevoir led it fl ux multimédia et le stocker dans ladite mémoire tampon BUF. Le processeur peut être un processeur central de l'ordinateur (qui peut être partagé avec d'autres circuits) ou un processeur dédié. La mémoire peut être une mémoire centrale de l'ordinateur (qui peut être partagée avec d'autres circuits) ou une mémoire dédiée. Il peut s'agir d'une mémoire non transitoire.
Le système d'émission comprend un circuit électronique d'émission EM_C d'un flux multimédia stocké dans la mémoire tampon BUF vers le périphérique multimédia MDEV. Selon une mise en œuvre possible, le circuit d'émission com prend u n processeur et u ne mémoire, lad ite mémoire contenant un programme d'ordinateur agencé pour émettre le flux multimédia stocké dans la mémoire tampon BUF vers le périphérique multimédia MDEV. Le processeur peut être un processeur central de l'ordinateur (qui peut être partagé avec d'autres circuits) ou un processeur dédié. La mémoire peut être une mémoire centrale de l'ordinateur (qui peut être partagée avec d'autres circuits) ou une mémoire dédiée. Il peut s'agir d'une mémoire non transitoire.
Selon un huitième mode de réalisation, un système d'émission de flux multimédia selon le septième mode de réalisation comprend un circuit électronique de réservation exclusive RES_C du périphérique multimédia MDEV pendant l'émission du flux multimédia. Selon une mise en œuvre possible, le circuit d'émission comprend un processeur et une mémoire, ladite mémoire contenant un programme d'ordinateur agencé pour réserver de façon exclusive le périphérique multimédia M DEV pendant l'ém ission du fl ux multimédia. Le processeur peut être un processeur central de l'ordinateur (qui peut être partagé avec d'autres circuits) ou un processeur dédié. La mémoire peut être une mémoire centrale de l'ordinateur (qui peut être partagée avec d'autres circuits) ou une mémoire dédiée. Il peut s'agir d'une mémoire non transitoire.
Selon un neuvième mode de réalisation, le module multimédia MM d'un système d'émission de flux multimédia selon le septième ou huitième mode de réalisation comprend u ne interface I NT accessi ble depu is u n lecteu r multimédia MPL exécuté par le processeur MP en mode utilisateur, le système d'émission comprenant un circuit électronique d'envoi SND_C de demande de sélection d'une position de lecture quelconque dans la mémoire tampon BUF au module multimédia MM par le lecteur multimédia MPL via ladite interface INT. Selon une mise en œuvre possible, le circuit d'envoi SND_C comprend un processeur et une mémoire, ladite mémoire contenant un programme d'ordinateur agencé pour envoyer une demande de sélection d'une position de lecture quelconque dans la mémoire tampon BUF au module multimédia MM par le lecteur multimédia MPL via ladite interface INT. Le processeur peut être un processeur central de l'ordinateur (qui peut être partagé avec d'autres circuits) ou un processeur dédié. La mémoire peut être une mémoire centrale de l'ordinateur (qui peut être partagée avec d'autres circuits) ou une mémoire dédiée. Il peut s'agir d'une mémoire non transitoire.
Un dixième mode de réalisation se rapporte à un système d'émission de flux multimédia selon l'un des septième au neuvième modes de réalisation, dans lequel le flux multimédia est un flux audio MUS et dans lequel le périphérique multimédia MDEV comprend un convertisseur numérique analogique DAC.
Bien entendu, la présente invention ne se limite pas à la forme de réalisation décrite ci-avant à titre d'exemple ; elle s'étend à d'autres variantes. Les caractéristiques décrites vis-à-vis des procédés selon l'invention se transposent aux systèmes correspond a nts selon l ' i nvention , et réciproquement. Les modes de réalisation décrits pour des morceaux de musique se transposent à d'autres types de flux multimédia, notamment à des flux vidéo, à des flux audio-vidéo, à des flux vidéo en réalité augmentée, voire à des flux d'informations commandant des dispositifs d'éclairage (projecteurs lumineux, lasers, etc.) ou des dispositifs électromécaniques (par exemple des flux pilotant des robots ou des servomoteurs reliés à des éléments d'une scène afin de réaliser des effets spéciaux dans le cadre d'un spectacle), dans des cas où une synchronisation très précise est requise.

Claims

REVENDICATIONS
1 . Procédé d'émission de flux multimédia (MUS, MOV) vers un périphérique multimédia (MDEV) d'un ordinateur (PC), l'ordinateur (PC) comprenant un processeur (MP) apte à fonctionner en mode utilisateur et en mode superviseur, l'ordinateur (PC) comprenant un support de stockage (HDD) lisible par le processeur (MP) et stockant un module multimédia (MM), le procédé d'émission comprenant au niveau du module multimédia (MM) exécuté par le processeur (MP) en mode superviseur :
/a/ une allocation (AL), en espace noyau, d'une mémoire tampon (BUF) agencée pour contenir au moins dix secondes de flux multimédia (MUS, MOV) ;
/b/ une réception (REC) d'un flux multimédia (MUS, MOV), et de son stockage dans la mémoire tampon (BUF) ;
Ici une émission (EM) d'un flux multimédia stocké dans la mémoire tampon (BUF) vers le périphérique multimédia (MDEV).
2. Procédé d'émission d e fl ux m u l ti m éd ia (M U S , M OV) selo n l a revendication 1 , comprenant une réservation exclusive (RES), par le module multimédia (MM), du périphérique multimédia (MDEV) pendant l'émission du flux multimédia.
3. Procédé d'émission de flux multimédia (MUS, MOV) selon la revendication 1 ou 2, le module multimédia (MM) comprenant une interface (INT) accessible depuis un lecteur multimédia (MPL) exécuté par le processeur (MP) en mode utilisateur, le procédé d'émission comprenant un envoi (SND) au module multimédia (MM), par le lecteur multimédia (MPL), via ladite interface (INT), d'une demande de sélection d'une position de lecture quelconque dans la mémoire tampon (BUF).
4. Procédé d'émission de flux multimédia selon l'une des revendications précédentes, dans lequel le flux multimédia comprend un flux audio (MUS) et dans lequel le périphérique multimédia (MDEV) comprend un convertisseur numérique analogique (DAC).
5. Prog ram me d'ord inateu r com prenant une série d' instructions qu i , lorsqu'elles sont exécutées par un processeur, mettent en œuvre un procédé selon l'une des revendications précédentes.
6. Support de stockage non transitoire lisible par ordinateur (HDD), comprenant un programme d'ordinateur selon la revendication 5.
7. Système d'émission de flux multimédia (MUS, MOV) comprenant:
- un ordinateur (PC) et
- un périphérique multimédia (MDEV),
l'ordinateur (PC) comprenant:
- un processeur (MP) apte à fonctionner en mode utilisateur et en mode superviseur, ainsi que
- un support de stockage (HDD) lisible par le processeur (MP) et stockant un module multimédia (MM),
le module multimédia (MM) étant agencé pour être exécuté par le processeur (MP) en mode superviseur,
le système d'émission comprenant :
- un circuit d'allocation (AL_C), en espace noyau, d'une mémoire tampon (BUF) agencée pour contenir au moins dix secondes de flux multimédia (MUS, MOV) ;
- un circuit de réception (REC_C) d'un flux multimédia (MUS, MOV), agencé pour recevoir ledit flux multimédia et le stocker dans la mémoire tampon (BUF) ;
- un circuit d'émission (EM_C) d'un flux multimédia stocké dans la mémoire tampon (BUF) vers le périphérique multimédia (MDEV).
8. Système d'émission d e fl u x m u l t i m éd i a (M U S , M OV) se l o n l a revendication 7, comprenant un circuit de réservation exclusive (RES_C) du périphérique multimédia (MDEV) pendant l'émission du flux multimédia.
9. Système d'émission de flux multimédia (MUS, MOV) selon la revendication 7 ou 8, le module multimédia (MM) comprenant une interface (INT) accessible depuis un lecteur multimédia (MPL) exécuté par le processeur (MP) en mode utilisateur, le système d'émission comprenant un circuit de d'envoi (SND_C) de demande de sélection d'une position de lecture quelconque dans la mémoire tampon (BUF) au module multimédia (MM) par le lecteur multimédia (MPL) via ladite interface (INT).
10. Système d'émission de flux multimédia selon l'une des revendications 7 à 9, dans lequel le flux multimédia comprend un flux audio (MUS) et dans lequel le périphérique multimédia (MDEV) comprend un convertisseur numérique analogique (DAC).
PCT/FR2016/050653 2015-03-27 2016-03-24 Amelioration d'emission de flux multimedia Ceased WO2016156702A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP16718407.6A EP3274830A1 (fr) 2015-03-27 2016-03-24 Amelioration d'emission de flux multimedia
JP2017549809A JP2018520398A (ja) 2015-03-27 2016-03-24 マルチメディアストリームの送信の改善
US15/558,079 US20180052786A1 (en) 2015-03-27 2016-03-24 Improvement in sending of multimedia streams

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1552617A FR3034220B1 (fr) 2015-03-27 2015-03-27 Amelioration d'emission de flux multimedia
FR1552617 2015-03-27

Publications (1)

Publication Number Publication Date
WO2016156702A1 true WO2016156702A1 (fr) 2016-10-06

Family

ID=53758324

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2016/050653 Ceased WO2016156702A1 (fr) 2015-03-27 2016-03-24 Amelioration d'emission de flux multimedia

Country Status (5)

Country Link
US (1) US20180052786A1 (fr)
EP (1) EP3274830A1 (fr)
JP (1) JP2018520398A (fr)
FR (1) FR3034220B1 (fr)
WO (1) WO2016156702A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018024953A1 (fr) * 2016-08-04 2018-02-08 Damien Plisson Systeme de decodage et de lecture audio

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10452339B2 (en) * 2015-06-05 2019-10-22 Apple Inc. Mechanism for retrieval of previously captured audio

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6209041B1 (en) * 1997-04-04 2001-03-27 Microsoft Corporation Method and computer program product for reducing inter-buffer data transfers between separate processing components
US20020032753A1 (en) * 1996-07-01 2002-03-14 Benjamin H. Stoltz Mixing and splitting multiple independent audio data streams in kernel space

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6212574B1 (en) * 1997-04-04 2001-04-03 Microsoft Corporation User mode proxy of kernel mode operations in a computer operating system
US6646195B1 (en) * 2000-04-12 2003-11-11 Microsoft Corporation Kernel-mode audio processing modules
US8639830B2 (en) * 2008-07-22 2014-01-28 Control4 Corporation System and method for streaming audio
US8375137B2 (en) * 2008-07-22 2013-02-12 Control4 Corporation System and method for streaming audio using a send queue

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020032753A1 (en) * 1996-07-01 2002-03-14 Benjamin H. Stoltz Mixing and splitting multiple independent audio data streams in kernel space
US6209041B1 (en) * 1997-04-04 2001-03-27 Microsoft Corporation Method and computer program product for reducing inter-buffer data transfers between separate processing components

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018024953A1 (fr) * 2016-08-04 2018-02-08 Damien Plisson Systeme de decodage et de lecture audio
FR3054944A1 (fr) * 2016-08-04 2018-02-09 Damien Plisson Systeme de decodage et de lecture audio
US10728592B2 (en) 2016-08-04 2020-07-28 Damien Plisson Audio decoding and reading system

Also Published As

Publication number Publication date
US20180052786A1 (en) 2018-02-22
FR3034220B1 (fr) 2017-03-10
FR3034220A1 (fr) 2016-09-30
EP3274830A1 (fr) 2018-01-31
JP2018520398A (ja) 2018-07-26

Similar Documents

Publication Publication Date Title
US8327009B2 (en) Method and system for providing real-time streaming media content
US20140189735A1 (en) Streaming media buffer points reflecting user behavior and interests
US11785298B2 (en) Automatic replacement of media content associated with a real-time broadcast
US8578431B2 (en) Adaptive timeshift service
US10782888B2 (en) Method and device for improving file system write bandwidth through hard disk track management
FR2979164A1 (fr) Controleur pour dispositifs de memorisation et procede de commande de dispositifs de memorisation
US11481142B2 (en) Method and device for downloading resources
CN112218115B (zh) 流媒体音视频同步的控制方法、装置、计算机设备
US12072850B2 (en) Virtual file system for dynamically providing media content
US11416208B2 (en) Audio metadata smoothing
CN105786539B (zh) 一种文件下载方法及装置
US20170125062A1 (en) Multiple views recording
EP3274830A1 (fr) Amelioration d'emission de flux multimedia
KR102700120B1 (ko) 컴퓨팅 디바이스에서 애플리케이션 업데이트를 위한 메모리 효율적인 소프트웨어 패치하기
US20120308200A1 (en) Contiguous media playback
FR2820846A1 (fr) Dispositif et procede de gestion d'acces a un support d'enregistrement
KR20100113758A (ko) 콘텐츠 다운로드 제어 장치 및 방법
US9111577B2 (en) Storage space savings via partial digital stream deletion
EP2413233B1 (fr) Téléphone mobile sous android comprenant une chaîne de mise à disposition de contenus
US9519574B2 (en) Dynamic content access window loading and unloading
US20240114199A1 (en) On-The-Edge Network For Generating Dynamic Digital Cinema Packages
US11558646B2 (en) Time shift buffer via flash memory
US11316945B2 (en) Vehicle multimedia system and memory management method therefor
KR101269052B1 (ko) 가상 콘텐츠 파일을 이용하는 콘텐츠 재생시스템 및 그 방법
CN116932318A (zh) 用于进行数据处理和传输的方法、装置及计算机可读介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16718407

Country of ref document: EP

Kind code of ref document: A1

REEP Request for entry into the european phase

Ref document number: 2016718407

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 15558079

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2017549809

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE