Abstract:
A method of operating a media player includes playing back audio media. During the step of playing back audio media, a maximum volume parameter is refined for the playing back of the media by the media player. The refining is based at least in part on the playing back of audio media during a time period prior to executing the maximum volume refining step. After a period of time, the maximum volume refining step is repeated. The refining is configured to prevent/minimize harm to hearing of the media player user based, for example, on the actual volume of media playback and time/duration profiles provided by occupational safety and/or other organizations.

Description:
BACKGROUND 
     Portable media players are becoming pervasive, particularly among relatively younger people. An unintended side effect of using such players is the damaging effect on the users&#39; hearing. The damaging effect on the users&#39; hearing may be exacerbated by new manners of use (all day use, versus for limited time periods such as during jogging) and, perhaps, by the configuration of the headphones (in the ear). 
     Furthermore, since the damaging effect on users&#39; hearing is both gradual and cumulative, even those users who are concerned about hearing loss may not behave with respect to their portable media players in a manner that would limit or minimize such damaging hearing effects. 
     SUMMARY 
     A method of operating a media player includes playing back audio media. During the step of playing back audio media, a maximum volume parameter is refined for the playing back of the media by the media player. The refining is based at least in part on the playing back of audio media during a time period prior to executing the maximum volume refining step. After a period of time, the maximum volume refining step is repeated. 
     The refining is configured to prevent/minimize harm to hearing of the media player user based, for example, on the actual volume of media playback and time/duration profiles provided by occupational safety and/or other organizations. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates a host application in detachable communication with a portable media player, including communication of an indication of protection parameters from the host application to the portable media player. 
         FIG. 2  is a flowchart illustrating processing in the portable media player for refining a maximum volume value based on an actual volume of media playback by the portable media player. 
         FIG. 3  illustrates a table of compensation factors, based on headphone type, employed in refining the maximum volume value. 
         FIG. 4  illustrates a table of compensation factors, based on song characteristics, employed in refining the maximum volume value. 
     
    
    
     DETAILED DESCRIPTION 
     In accordance with a broad aspect, a portable media player processes protection parameters to control the playback of media by the portable media player. During use of the portable media player and based on actual use of the portable media player, the protection parameters are adjusted. Thus, for example, the adjustment of the protection parameters may take into account volume of playback in actual use, including duration of playback. 
     In one example, a “credit” accounting is maintained for determining the protection parameters, where credits are subtracted based on actual use that has first particular characteristics, whereas credits are added based on actual use that has second particular characteristics. For example, the first particular characteristics may be characteristics for which it has been determined to have a relatively damaging cumulative effect on hearing (e.g., relatively “loud” playback), whereas the second particular characteristics may be characteristics for which it has been determined to not have a relatively damaging cumulative effect on hearing (e.g., relatively “soft” playback, that allows recovery from the relatively damaging cumulative effect on hearing). 
       FIG. 1  broadly illustrates one example of an architecture that uses protection parameters. As shown in  FIG. 1 , a host application  102  executing on a computer interfaces with a portable media player  104 . The host application  102  may be, for example, the iTunes® software provided by Apple Computer, Inc. In one example, a user (e.g., a parent of the user of the portable media player  104 ) interacts with the host application  102  to choose a protection profile. The protection profile may be based, for example, on a desired level of protection (such as “low,” “medium” and “high”) or on an age of the user (e.g., assuming that a younger user requires more constraints). 
     As also shown in  FIG. 1 , an indication of protection parameters is provided from the host application  102  to the portable media player  104 . The protection parameters may be pre-stored on the portable media player  104 , with a signal being provided to from the host application  102  to the portable media player  104  that indicates which protection parameters to use. In other examples, a user of the portable media player  104  interacts directly with the portable media player  104  to cause the protection parameters to be indicated. Indication of the protection parameters may also be a result of interaction with both the host application  102  and the portable media player  104 . 
     In the portable media player  104 , a controller  106  processes the protection parameters to determine threshold playback characteristics, such as maximum playback volume or characteristics that are an indication of (and/or contribute to) the maximum playback volume. The actual playback by the portable media player, by audio output circuitry  108 , is thus constrained by the determined threshold playback characteristics. Moreover, the threshold playback characteristics are adjusted by the controller based on characteristics of the actual playback operation of the portable media player  104 . In some examples, the threshold playback characteristics are determined on the host, by the host application  102 . 
       FIG. 2  is a flowchart illustrating an example of processing within the controller  106  of the portable media player  104  ( FIG. 1 ) to accomplish enforcing the protection parameters. The controller may operate, for example, in a programmed manner based on software or firmware instructions. However, the controller is not limited, for example, to being a processor that executes instructions. In the  FIG. 2  example, a “credit” scheme is employed. It is noted that this is an example, and other types of schemes may be employed. Turning now specifically to  FIG. 2 , at step  202 , an initial number of credits is determined based on the protection parameters indicated or provided by the host application  102 . 
     At step  204 , a maximum allowed volume parameter, indicative of a maximum volume allowed for the next timer period “x” is determined based on the determined credits. In one particular example, the maximum allowed volume is determined based on the determined credits with reference to a profile such as profiles provided by the California Occupational Safety and Health Administration (Cal-OSHA). See, for example, Cal-OSHA Regulations—Control of Noise Exposures, in the California Code of Regulations, Title 8, Section 5096-5100 Article 105 and, see also, Permissible Noise Exposure—Table N-1 of the just-referenced regulation. It is noted that the profiles promulgated by Cal-OSHA appear to be rudimentary (e.g., do not deal in a sophisticated way with varying exposure over time and do not deal account for “recovery”). Thus, in some examples, more sophisticated profiles are employed. 
     At step  206 , during the time period “x”, the actual volume is controlled based on the determined maximum volume for the time period “x.” Details according to particular examples are discussed later. 
     At step  208 , the credits are recalculated based on the actual volume during the timer period “x.” For example, if the user of the portable media player set the desired volume to be less than the determined maximum volume (or, perhaps, less than some other volume that is less than the determined maximum volume), then this may have allowed the user&#39;s hearing some “recovery” such that credits can be granted. That is, the credits may be usable to increase the determined maximum volume (as determined at step  204 ) for a future time period “x.” After the credits are recalculated, then processing returns to step  204  for the next time period “x.” 
     We now discuss, with reference to  FIGS. 3 and 4 , how step  204  processing may be affected by factors other than those purely within the profiles.  FIG. 3  is an example of compensation factors that are utilized for various types of headphones. That is, the compensation factors may be factors that indicate (and, thus, are used as parameters to the formulas) how the formula may be modified for a particular headphone such that the formula more accurately reflects reality. For example, for a particular volume of sound output, one headphone may have characteristics versus characteristics of another headphone such that the first headphone does not have as deleterious effect on hearing as does the second headphone, even at the same particular volume of sound output. In various examples, compensation factors are provided for general types of headphones (e.g., earbud, over the ear, etc.) and, in other examples, the compensation factors are more specific, provided for various models of headphones. 
       FIG. 4  illustrates another example of compensation factor. In particular,  FIG. 4  illustrates providing a compensation factor that characterizes the media that is being played. In one example, the characteristic is a characteristic (or is based on a characteristic) that has been determined by a Soundcheck feature of iTunes, indicating an approximate audio level of the song. 
     We now discuss details of an example of controlling the volume during time period “x” based on the determined maximum volume. In one example, the determined maximum volume is treated as a threshold. Thus, if the user of the portable media player sets the volume to a desired volume that is greater than the determined maximum volume for the time period “x,” then the actual playback volume is set to the determined maximum volume. On the other hand, if the user of the portable media player sets the volume to a desired volume that is less than the determined maximum volume for the timer period “x,” then the actual playback volume is set to the desired volume. 
     In another example, the indication of the determined maximum volume parameter is used in step  206  as a scale factor, such that the actual volume of audio output is the desired volume, scaled down by the scale factor. 
     In addition to lowering of the volume in step  206  leading to additional credits in step  208 , a complete cessation of playing the media player should also lead to additional credits upon restarting of playing. Thus, in one example, when audio output is stopped, the time of cessation is stored such that, upon restarting of playing, the time between cessation and restarting can be treated as a “quiet” time during which recovery has taken place and for which credits should be added. 
     In other examples, at step  204 , the determined maximum volume may be either zero or “indeterminate” (i.e., whatever volume the user desires). In these examples, then, the processing at step  206  operates to control the volume only when the determine maximum volume is zero—shutting down the audio output of the media player. At step  208 , as part of the recalculating step, a user interface function may be provided to give the user of the portable media player an indication of how many credits remain. This indication may be, for example, an indication of how long output will be allowed at the current actual volume, based on the remaining credits. The indication may be a simple binary indication (such as flashing when only a threshold amount of time remains). 
     In some examples, causing the indication of the protection parameters is secure such that, for example, a parent could securely set the protection parameters for a child user of the portable media player. In one example, the host software  102  is used to create a tamperproof (or tamper-resistant) configuration file as described, for example, in U.S. patent application Ser. No. 11/191,133, entitled CONFIGURATION OF A COMPUTING DEVICE IN A SECURE MANNER, filed on Jul. 26, 2005 (the disclosure of which is incorporated herein in its entirety). 
     Furthermore, the discussion thus far has been in the context of a portable media player. However, in some examples, the concepts discussed herein are also applicable to audio devices such as, for example, cellular phones. With some audio devices, the audio playback characteristics can not (or, at least, cannot primarily) be determined in advance. For example, while playback characteristics of a song can be determined in advance (as illustrated by  FIG. 4 , for example), the levels of a voice speaking over a cellular phone connection typically cannot be determined in advance. Thus, in such situations, recalculating the credits (or otherwise adjusting how volume is to be controlled) may be more complicated, since more sophisticated monitoring of actual volume may be required. 
     While this invention has been described in terms of several embodiments, there are alterations, permutations, and equivalents, which fall within the scope of this invention. It should also be noted that there are many alternative ways of implementing the methods and apparatuses of the present invention. It is therefore intended that the following appended claims be interpreted as including all such alterations, permutations, and equivalents as fall within the true spirit and scope of the present invention.