提供采样音频服务

原文： https://docs.oracle.com/javase/tutorial/sound/SPI-providing-sampled.html

如您所知，Java Sound API 包括两个包javax.sound.sampled.spi和javax.sound.midi.spi，它们定义了声音服务开发人员使用的抽象类。通过实现和安装这些抽象类之一的子类，服务提供者注册新服务，扩展运行时系统的功能。此页面告诉您如何使用javax.sound.sampled.spi包提供处理采样音频的新服务。

javax.sound.sampled.spi包中有四个抽象类，表示可以为采样音频系统提供的四种不同类型的服务：

  • AudioFileWriter 提供声音文件写入服务。这些服务使应用程序可以将音频数据流写入特定类型的文件。
  • AudioFileReader 提供文件读取服务。这些服务使应用程序能够确定声音文件的特征，并获得可以从中读取文件音频数据的流。
  • FormatConversionProvider 提供转换音频数据格式的服务。这些服务允许应用程序将音频流从一种数据格式转换为另一种数据格式。
  • MixerProvider provides management of a particular kind of mixer. This mechanism allows an application program to obtain information about, and access instances of, a given kind of mixer.

为了概括早期的讨论，服务提供商可以扩展运行时系统的功能。典型的 SPI 类有两种类型的方法：响应有关特定提供者可用服务类型的查询，以及直接执行新服务或返回实际提供服务的对象实例。运行时环境的服务提供者机制提供已安装服务的注册与音频系统，以及新服务提供者类的管理。

本质上，应用程序开发人员对服务实例进行了双重隔离。应用程序永远不会直接创建服务对象的实例，例如混音器或格式转换器，它们需要用于音频处理任务。程序甚至也不直接从管理它们的 SPI 类请求这些对象。应用程序向javax.sound.sampled包中的AudioSystem对象发出请求，AudioSystem依次使用 SPI 对象处理这些查询和服务请求。

新的音频服务的存在对用户和应用程序员来说可能是完全透明的。所有应用程序引用都是通过javax.sound.sampled包的标准对象，主要是AudioSystem，新服务可能提供的特殊处理通常是完全隐藏的。

在本讨论中，我们将继续使用AcmeMixer和AcmeMixerProvider等名称引用新 SPI 子类的先前惯例。

提供音频文件写入服务

让我们从AudioFileWriter开始，这是一个更简单的 SPI 类。

实现AudioFileWriter方法的子类必须提供一组方法的实现来处理有关类支持的文件格式和文件类型的查询，并提供实际写出提供的方法音频数据流到File或OutputStream。

AudioFileWriter包括两个在基类中具体实现的方法：

  1. boolean isFileTypeSupported(AudioFileFormat.Type fileType) 
  2. boolean isFileTypeSupported(AudioFileFormat.Type fileType, AudioInputStream stream)

第一个方法通知调用者此文件编写器是否可以写入指定类型的声音文件。该方法是一般查询，如果文件编写者可以写入那种文件，则返回true，假设文件编写者传递了适当的音频数据。但是，写入文件的能力可能取决于传递给文件编写器的特定音频数据的格式。文件编写器可能不支持每种音频数据格式，或者文件格式本身可能强加约束。 （并非所有类型的音频数据都可以写入各种声音文件。）第二种方法更具体，然后询问是否可以将特定的AudioInputStream写入特定类型的文件。

通常，您不需要覆盖这两个具体方法。每个都只是一个包装器，它调用另外两个查询方法之一并迭代返回的结果。这两个查询方法是抽象的，因此需要在子类中实现：

  1. abstract AudioFileFormat.Type[] getAudioFileTypes() 
  2. abstract AudioFileFormat.Type[] getAudioFileTypes(AudioInputStream stream)

这些方法直接对应于前两个。每个返回所有支持的文件类型的数组 - 在第一种方法的情况下通常支持的所有类型，以及在第二种方法的情况下支持特定音频流的所有类型。第一种方法的典型实现可能只返回文件编写器的构造器初始化的数组。第二种方法的实现可能会测试流的AudioFormat对象，以查看它是否是所请求的文件类型支持的数据格式。

AudioFileWriter的最后两个方法进行实际的文件写入工作：

  1. abstract int write(AudioInputStream stream, 
  2.      AudioFileFormat.Type fileType, java.io.File out) 
  3. abstract int write(AudioInputStream stream, 
  4.      AudioFileFormat.Type fileType, java.io.OutputStream out)

这些方法将表示音频数据的字节流写入由第三个参数指定的流或文件。如何完成此操作的详细信息取决于指定类型的文件的结构。 write方法必须以这种格式的声音文件规定的方式写入文件的标题和音频数据（无论是标准类型的声音文件还是新的，可能是专有的声音文件）。

提供音频文件阅读服务

AudioFileReader类由子类需要实现的六个抽象方法组成 - 实际上是两个不同的重载方法，每个方法都可以采用File，URL或InputStream参数。第一个重载方法接受有关指定文件的文件格式的查询：

  1. abstract AudioFileFormat getAudioFileFormat(java.io.File file) 
  2. abstract AudioFileFormat getAudioFileFormat(java.io.InputStream stream) 
  3. abstract AudioFileFormat getAudioFileFormat(java.net.URL url)

getAudioFileFormat方法的典型实现是读取和解析声音文件的标题以确定其文件格式。请参阅 AudioFileFormat 类的说明，以查看需要从标头中读取哪些字段，并参阅特定文件类型的规范以了解如何解析标头。

因为提供流作为此方法的参数的调用者希望该方法不改变流，所以文件读取器通常应该首先标记流。读到标题的末尾后，它应该将流重置为其原始位置。

另一个重载AudioFileReader方法通过返回一个 AudioInputStream 来提供文件读取服务，从中可以读取文件的音频数据：

  1. abstract AudioInputStream getAudioInputStream(java.io.File file) 
  2. abstract AudioInputStream getAudioInputStream(java.io.InputStream stream) 
  3. abstract AudioInputStream getAudioInputStream(java.net.URL url)

通常，getAudioInputStream的实现将AudioInputStream返回到文件数据块的开头（在标题之后），准备好进行读取。但是，可以想象，文件阅读器返回AudioInputStream，其音频格式表示以某种方式从文件中包含的内容解码的数据流。重要的是该方法返回一个格式化的流，可以从中读取文件中包含的音频数据。封装在返回的AudioInputStream对象中的AudioFormat将通知调用者流的数据格式，该格式通常但不一定与文件本身的数据格式相同。

通常，返回的流是AudioInputStream的实例;您不太可能需要子类化AudioInputStream。

提供格式转换服务

A FormatConversionProvider子类将具有一种音频数据格式的AudioInputStream转换为具有另一种格式的格式。前（输入）流被称为源流，后者（输出）流被称为目标流。回想一下AudioInputStream包含AudioFormat，而AudioFormat又包含特定类型的数据编码，由AudioFormat.Encoding对象表示。源流中的格式和编码称为源格式和源编码，目标流中的格式和编码同样称为目标格式和目标编码。

转换工作在FormatConversionProvider的重载抽象方法getAudioInputStream中执行。该类还具有抽象查询方法，用于了解所有受支持的目标和源格式以及编码。有查询特定转换的具体包装方法。

getAudioInputStream的两个变种是：

  1. abstract AudioInputStream getAudioInputStream(AudioFormat.Encoding targetEncoding, 
  2.      AudioInputStream sourceStream)

和

  1. abstract AudioInputStream getAudioInputStream(AudioFormat targetFormat, 
  2.      AudioInputStream sourceStream)

根据调用者是指定完整的目标格式还是仅指定格式的编码，它们在第一个参数中不同。

getAudioInputStream的典型实现是通过返回包含原始（源）AudioInputStream的新AudioInputStream子类来工作，并且只要read方法是，就将数据格式转换应用于其数据调用。例如，考虑一个名为AcmeCodec的新FormatConversionProvider子类的情况，该子类与名为AcmeCodecStream的新AudioInputStream子类一起使用。

AcmeCodec's第二getAudioInputStream方法的实现可能是：

  1. public AudioInputStream getAudioInputStream
  2.       (AudioFormat outputFormat, AudioInputStream stream) {
  3.         AudioInputStream cs = null;
  4.         AudioFormat inputFormat = stream.getFormat();
  5.         if (inputFormat.matches(outputFormat) ) {
  6.             cs = stream;
  7.         } else {
  8.             cs = (AudioInputStream)
  9.                 (new AcmeCodecStream(stream, outputFormat));
  10.             tempBuffer = new byte[tempBufferSize];
  11.         }
  12.         return cs;
  13.     }

实际的格式转换发生在返回的AcmeCodecStream的新read方法中，AudioInputStream是AudioInputStream的子类。同样，访问此返回AcmeCodecStream的应用程序只是作为AudioInputStream对其进行操作，并且不需要知道其实现的细节。

FormatConversionProvider的其他方法都允许查询对象支持的输入和输出编码和格式。需要实现以下四种抽象方法：

  1. abstract AudioFormat.Encoding[] getSourceEncodings() 
  2. abstract AudioFormat.Encoding[] getTargetEncodings() 
  3. abstract AudioFormat.Encoding[] getTargetEncodings(
  4.     AudioFormat sourceFormat) 
  5. abstract  AudioFormat[] getTargetFormats(
  6.     AudioFormat.Encoding targetEncoding, 
  7.     AudioFormat sourceFormat)

与上面讨论的AudioFileReader类的查询方法一样，这些查询通常通过检查对象的私有数据来处理，对于后两种方法，将它们与参数进行比较。

其余四种FormatConversionProvider方法是具体的，通常不需要覆盖：

  1. boolean isConversionSupported(
  2.     AudioFormat.Encoding targetEncoding,
  3.     AudioFormat sourceFormat) 
  4. boolean isConversionSupported(AudioFormat targetFormat, 
  5.     AudioFormat sourceFormat) 
  6. boolean isSourceEncodingSupported(
  7.     AudioFormat.Encoding sourceEncoding) 
  8. boolean isTargetEncodingSupported(
  9.     AudioFormat.Encoding targetEncoding)

与AudioFileWriter.isFileTypeSupported()一样，每个方法的默认实现本质上是一个包装器，它调用其他查询方法之一并迭代返回的结果。

提供新型混合器

顾名思义，MixerProvider提供混音器实例。每个具体的MixerProvider子类充当应用程序使用的Mixer对象的工厂。当然，如果还定义了Mixer接口的一个或多个新实现，则定义新的MixerProvider才有意义。与上面的FormatConversionProvider示例一样，我们的getAudioInputStream方法返回执行转换的AudioInputStream的子类，我们的新类AcmeMixerProvider有一个方法getMixer，它返回另一个实现该类的新类的实例。 Mixer接口。我们称之为后一类AcmeMixer。特别是如果混合器以硬件实现，则提供者可能仅支持所请求设备的一个静态实例。如果是这样，它应该返回此静态实例以响应getMixer的每次调用。

由于AcmeMixer支持Mixer接口，因此应用程序不需要任何其他信息即可访问其基本功能。但是，如果AcmeMixer支持Mixer接口中未定义的功能，并且供应商希望使应用程序可以访问此扩展功能，那么混音器当然应该被定义为公共类，其中包含额外的，记录良好的公共方法，以便希望使用此扩展功能的程序可以导入AcmeMixer并将getMixer返回的对象转换为此类型。

MixerProvider的另外两种方法是：

  1. abstract Mixer.Info[] getMixerInfo()

和

  1. boolean isMixerSupported(Mixer.Info info)

这些方法允许音频系统确定此特定供应器类是否可以生成应用程序所需的设备。换句话说，AudioSystem对象可以迭代所有已安装的MixerProviders，以查看哪些（如果有的话）可以为应用程序请求AudioSystem的设备供电。 getMixerInfo方法返回一个对象数组，其中包含有关此供应器对象可用的混合器类型的信息。系统可以将这些信息对象以及来自其他提供者的信息对象传递给应用程序。

单个MixerProvider可以提供多种混合器。当系统调用MixerProvider's getMixerInfo方法时，它会获得一个信息对象列表，用于标识此供应器支持的不同类型的混合器。然后系统可以调用MixerProvider.getMixer(Mixer.Info)以获得每个感兴趣的混频器。

你的子类需要实现getMixerInfo，因为它是抽象的。 isMixerSupported方法是具体的，通常不需要重写。默认实现只是将提供的Mixer.Info与getMixerInfo返回的数组中的每一个进行比较。