当我开始播放时,请求被调用,start=null 和 end=null。 当播放完这些字节后,就没有额外的请求调用了。
我已经为此苦苦挣扎了几天,每个不同的实现都会遇到不同的错误。所以欢迎所有的建议。我从 OpenAI TTS 端点进行流式传输。
class MyCustomSource extends StreamAudioSource {
List<int> bytes = [];
Stream<List<int>> byteStream;
MyCustomSource(this.byteStream) {
byteStream.listen((event) {
this.bytes.addAll(event);
});
print("Added ${bytes.length} bytes to List<int>");
}
@override
Future<StreamAudioResponse> request([int? start, int? end]) async {
print("Request called with start: $start and end: $end");
print("Bytes.lenght: ${bytes.length}");
start??=0;
end??=bytes.length;
return StreamAudioResponse(
rangeRequestsSupported: true,
sourceLength: null, // this should indicate that we don't know the full lenght of the stream
contentLength: end-start,
offset: start,
stream: Stream.value(bytes.sublist(start, end)),
contentType: 'audio/mpeg',
);
}
}
让我们解决这个问题:
MyCustomSource
的初始化:当您创建MyCustomSource
的实例时,您将向其传递一个byteStream
。该流似乎是您的音频数据的来源。
处理流中的字节:您正在监听
byteStream
并将接收到的 bytes
附加到 MyCustomSource
类中的字节列表中。
request
方法实现:此方法负责在玩家请求时提供数据。它旨在处理部分字节范围请求。
然后问题似乎可能出在
request
方法的实现上。需要注意的一件事是,从代码中不清楚初始设置后何时应触发 request
方法。它应该由任何正在消耗您的 MyCustomSource
的音频播放器或系统调用。
但是,这里我们有一些需要考虑的事情和潜在的改进:
触发请求:确保在需要更多音频数据时(即,当玩家前进或请求更多音频时),消耗 MyCustomSource 的任何内容都会适当地触发请求方法。
处理字节范围:仔细检查请求方法中的逻辑。通过提供字节列表中请求的音频数据部分,确保您正确处理字节范围请求。
调试:添加更多调试打印或日志记录语句来跟踪请求方法被调用的时间和方式,以及它接收的开始和结束值。
错误处理:考虑如何处理错误,尤其是当请求的范围(开始到结束)超出可用字节时。