gpt4 book ai didi

java - Android:音轨(流模式)在写入之间切换

转载 作者:行者123 更新时间:2023-12-02 10:22:39 26 4
gpt4 key购买 nike

我的主要目标是能够将音频从一台设备流式传输到 LAN 中的另一台设备。我计划通过将 mp3 文件读入 byte[] (我已经开始工作)并将其作为 udp 数据包发送到第二个设备并在那里播放来实现此目的(我告诉你这一点,以防万一这已经是错误的做法)。我目前一直在玩我的字节数组。我使用 mp3 中的 decoder(path, startMs,urationMs) 函数读取我的文件。目前我能够听到音频,但在每次滴答声(这是我读取文件的部分)之后,我在几毫秒内听不到任何声音,这导致了糟糕的聆听体验。我认为这与缓冲区大小有关,并尝试使用它,但这并没有真正改变什么,以及添加 AudioTrack.WRITE_NON_BLOCKING。我还考虑过将每个 for() 循环放在不同的线程中,但这根本不起作用(这是有道理的)。我也已经尝试先读取文件并将我的 byte[] 放入 Arraylist 中,因为这可能是文件读取缓慢导致的问题,但仍然是相同的体验。了解 Log.e("DEBUG", "Length "+ data.length); 仅在每个刻度显示,这意味着写入也仅在每个刻度发生(这可能是问题)。我怎样才能去掉歌曲中的这些空白部分?

这是单击按钮时执行的代码:

song.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View view) {
Thread thrd = new Thread(new Runnable() {
@Override
public void run() {
try {
int tick = 1000;
int max = 9000;
int sampleRate = 44100;
int bufSize = AudioTrack.getMinBufferSize(sampleRate*4, AudioFormat.CHANNEL_OUT_STEREO, AudioFormat.ENCODING_PCM_16BIT);
byte[] data = decode(path, 0, tick);
AudioTrack track = new AudioTrack(AudioManager.STREAM_MUSIC,
44100, AudioFormat.CHANNEL_OUT_STEREO,
AudioFormat.ENCODING_PCM_16BIT, bufSize,
AudioTrack.MODE_STREAM, AudioTrack.WRITE_NON_BLOCKING);
track.play();
track.write(data, 0, data.length);
Log.e("DEBUG", "Length " + data.length);
for(int i = tick; i < max; i+=tick) {
data = decode(path, i, tick);
track.write(data, 0, data.length);
Log.e("DEBUG", "Length " + data.length);
}
} catch (IOException e) {
e.printStackTrace();
}
}
});
thrd.start();
}
});

我的 decode() 函数(基于 this tutorial )与 JLayer 1.0.1:

public static byte[] decode(String path, int startMs, int maxMs)
throws IOException {
ByteArrayOutputStream outStream = new ByteArrayOutputStream(1024);

float totalMs = 0;
boolean seeking = true;

File file = new File(path);
InputStream inputStream = new BufferedInputStream(new FileInputStream(file), 8 * 1024);
try {
Bitstream bitstream = new Bitstream(inputStream);
Decoder decoder = new Decoder();

boolean done = false;
while (! done) {
Header frameHeader = bitstream.readFrame();
if (frameHeader == null) {
done = true;
} else {
totalMs += frameHeader.ms_per_frame();

if (totalMs >= startMs) {
seeking = false;
}

if (!seeking) {
SampleBuffer output = (SampleBuffer) decoder.decodeFrame(frameHeader, bitstream);

if (output.getSampleFrequency() != 44100
|| output.getChannelCount() != 2) {
Log.w("ERROR", "mono or non-44100 MP3 not supported");
}

short[] pcm = output.getBuffer();
for (short s : pcm) {
outStream.write(s & 0xff);
outStream.write((s >> 8) & 0xff);
}
}

if (totalMs >= (startMs + maxMs)) {
done = true;
}
}
bitstream.closeFrame();
}
} catch (BitstreamException e) {
throw new IOException("Bitstream error: " + e);
} catch (DecoderException e) {
Log.w("ERROR", "Decoder error", e);
} finally {
inputStream.close();
}
return outStream.toByteArray();
}

我不认为解码函数有问题,因为返回的 byte[] 似乎相当不错。也许稍后可以优化读取过程,当我真正流式传输音频并总是读取大约 10 毫秒的部分时,总是打开和关闭文件可能是一个问题。

最佳答案

问题的根本原因是:您使用 decode() 函数的方式并非专门设计的。尽管看起来 decode() 可以让您以随机访问方式解码 .mp3 流的任何部分,但实际上返回音频的前几毫秒总是静音,无论您是从歌曲的开头还是中间开始。这种沉默造成了“间隙”。显然,decode() 函数更多地用于在随机位置重新启动播放,例如由于用户“寻找”而导致的播放。

decode() 之所以如此,是因为为了解码第 N 个压缩数据 block ,解码器需要 block N-1 block N。对应于 block N 的数据会很好,但是 block N-1 的数据将会有这种“淡入”声音。这是 .mp3 解码器的一般特征,我知道 AAC 也会发生这种情况。同时,解码 block N+1、N+2、N+3等是没有问题的,因为在每种情况下,解码器都已经拥有前一个 block 。

一种解决方案是更改 decode() 函数:

private Decoder decoder;
private float totalMs;
private Bitstream bitstream;
private InputStream inputStream;

//call this once, when it is time to start a new song:
private void startNewSong(String path) throws IOException
{
decoder = new Decoder();
totalMs = 0;
File file = new File(path);
inputStream = new BufferedInputStream(new FileInputStream(file), 8 * 1024);
bitstream = new Bitstream(inputStream);
}

private byte[] decode(String path, int startMs, int maxMs)
throws IOException {
ByteArrayOutputStream outStream = new ByteArrayOutputStream(1024);


try {
boolean done = false;
while (! done) {
Header frameHeader = bitstream.readFrame();
if (frameHeader == null) {
done = true;
inputStream.close(); //Note this change. Now, the song is done. You can also clean up the decoder here.
} else {
totalMs += frameHeader.ms_per_frame();

SampleBuffer output = (SampleBuffer) decoder.decodeFrame(frameHeader, bitstream);

if (output.getSampleFrequency() != 44100
|| output.getChannelCount() != 2) {
Log.w("ERROR", "mono or non-44100 MP3 not supported");
}

short[] pcm = output.getBuffer();
for (short s : pcm) {
outStream.write(s & 0xff);
outStream.write((s >> 8) & 0xff);
}

if (totalMs >= (startMs + maxMs)) {
done = true;
}
}
bitstream.closeFrame();
}
} catch (BitstreamException e) {
throw new IOException("Bitstream error: " + e);
} catch (DecoderException e) {
Log.w("ERROR", "Decoder error", e);
}
return outStream.toByteArray();
}

该代码有点粗糙且准备就绪,需要一些改进。但一般方法是,decode() 使用 FSM 而不是随机访问。每次解码更多一点的歌曲;读取更多的文件内容,并向解码器发送更多的 block 。由于每次调用 decode() 之间都会保留解码器(和比特流)状态,因此无需寻找 block N-1。

UDP 和流媒体

UDP 方法的有效性取决于很多因素。您可能想寻找其他专门解决该问题的问题。 UDP 可以方便地向给定子网上的多个设备进行广播,但它无法帮助您确保按顺序接收数据包,或者根本无法确保数据包被接收。您可能需要 TCP。还要考虑是否要传输编码的 .mp3 block (由 bitstream.readFrame() 返回的 block )或解压缩的音频 block 。还要考虑如何处理网络延迟、连接断开和缓冲。这里需要做出许多困难的设计决策,每个选择都有优点和缺点。祝你好运。

关于java - Android:音轨(流模式)在写入之间切换,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/54222526/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com