Minor version bump (release 3.1.0)

[arkq]

No description provided.

[arkq]

@borine do you have any thoughts if anything should be added to master before making a new release? I thought about few commits from PR #425 but I'm worried that it's not tested enough, so adding it to master and making a new release right away is a horrible idea :D

[borine]

@arkq There's nothing else that comes to mind as being urgent at present. Tomorrow I'll take a quick glance at outstanding issues just to see if there's anything minor that can now be changed in the code or docs to help resolve them. I already have new drafts of the pcm plugin wiki articles, and I'll upload them as soon as the new release is out.

I haven't used the latest push to PR #425 yet, and I agree that the changes already in master are valuable enough to justify a release in their own right.

[arkq]

Tomorrow I'll take a quick glance at outstanding issues just to see if there's anything minor that can now be changed in the code or docs to help resolve them.

I much appreciate that. So I will postpone release until your acknowledgment in that matter.

To be honest, I don't know how to thank you for helping in answering to issues/questions in this project. I do really admire that you've got so much time and patience for that :) Not to mention the excellent wiki articles. I know how time consuming that is...

[borine]

The only addition for the release I have to suggest is PR #456.

The other thought I had is: bluealsa-cli monitor verbose - include PCM properties with the PCMAdded message. That should help with scripting solutions for dynamic management of ALSA configs. I think that needs more than a few days to get right, so is probably best left out for this release.

you've got so much time and patience

Covid lockdown has given me too much free time this last 12 months, contributing to this project has helped me keep busy!

[borine]

All looks good.

BTW I think there are many old open issues that should be closed as the code base has changed so much since they were last updated. If you want I could slowly work through them and close the stale ones.

[arkq]

BTW I think there are many old open issues that should be closed as the code base has changed so much since they were last updated.

Yes, I know. From time to time I'm reviewing them and I'm closing resolved ones or really really stale ones. Sometimes I'm not entirely sure whether to close an issue or not because even though the main "issue" was resolved there are some other "issues" in comments. I would be really grateful if you could look at them and close the stale ones. However, I'm not sure how to address issues which are not issues per se, more like questions... Maybe, since now github provides the discussion board (which in my opinion is stupid, stackoverflow is much better) it would be a good idea to convert non-issues to discussions (?).

[borine]

My personal opinion is that an issue that has had no updates in a long time (maybe 1 year, maybe 2) should be closed.

If is a genuine bug report then normally with a comment suggesting that if the problem persists in the latest code then a new issue should be raised with logs from the new code. Otherwise lots of outdated advice and comment remains "open" which can only confuse new users searching for keywords.

For general questions which remain unanswered we should accept that no-one is likely to answer after so much time, so maybe the closing comment should just say the authors can re-open if they are still interested.

Only if it is a known bug which might one day be fixed should a stale issue remain open

But that's just me - I certainly don't want to dive into the issue list here without first knowing your preferences in this matter

[arkq]

Hmm maybe you are right that old issues introduce a confusion only.

There is however one very old issue which is still valid: #15 I know that that bug is still there because I experience it from time to time, but I don't know what is causing it. In my case reproduction is very easy:

1. Take an old USB drive (not SSD) and store a movie on it.
2. Wait until drive spins down and goes to sleep.
3. Use mpv to play the file.

As a result the A-V will be out of sync. But then pause movie, wait few seconds until audio stops, then resume, There is no A-V sync issue now.... But what is the cause of this, I don't know. I suspect that there is an issue with time calculation in IO thread, so the thread does not wait but spits data right away until socket buffer is full. After a resume, the time counter is set to 0, so time drift is calculated properly.

Other than that I don't know whether issues are legitimate. So maybe it would be a good idea to close them. Maybe there is some kind of automation for that - bot or something. I think that I've seen once a project where there was a bot which was adding a comment to stale issues, that if there will be no activity within a month, the issue will be closed. Maybe something like this would be a good idea.

[borine]

There is however one very old issue which is still valid: #15 I know that that bug is still there because I experience it from time to time, but I don't know what is causing it. In my case reproduction is very easy:

I can't reproduce this. AV sync is always very good for me. Seagate Momentus 5400 rpm SATA disk on a cheap USB-SATA converter. Using sudo hd-idle -t /dev/sdb to sleep the disk. The disk is old and noisy, it is very easy to tell when it is spun down. Does the test file have to be a particular container type or codecs?

[arkq]

I can't reproduce this.

I think that the desync is not at as severe as it was few months (commits) ago, anyway I think that it is still there. Maybe the commit 42dd5c2 has fixed it somehow....

I'm using (mostly) AAC codec with VBR. It happens when I start playing a ~1GB movie file with mpv (maybe that's got something to do). With smaller files there is no issue.

Anyway, I've just checked with SBC and indeed it seems that there is no issue with SBC codec. What I suspect is that the problem might be with my headset (Jabra MOVE) with AAC codec with VBR. When the movie starts almost always there is a silence at the beginning, so after VBR encoding the amount of data is rather small, so maybe headset is able to fill its buffers with more "time"... which produces from 0.5 to 1 second of delay. With the current master (and new mpv and new alsa-lib) the delay is only 0.5 second, so not a big issue.