Closed gegeweb closed 3 years ago
Yes. This looks much more structured!
If I understood correctly, this page will be the official page maintained with up-to-date information. A page on the community area will be completed by the users. Right?
I don't know about this exactly but I think there should be one list only. Everyone is free to add things to the list (or improve the docs in general).
This list seems to be a natural for a community effort really, since none of us are going to be able to ensure accuracy over time are we? And again, the test here being: is this content needed for everyone on any given platform to actually use Jamulus? If yes, then it's official documentation, if no then it's community content.
This list seems to be a natural for a community effort really, since none of us are going to be able to ensure accuracy
Agree. Otherwise, if the device works on the system with other applications, there is no reason why it should not work with Jamulus, unless it does not support 48KHz. so …
the test here being: is this content needed for everyone on any given platform to actually use Jamulus? If yes, then it's official documentation, if no then it's community content.
… Actual tittle of this page is Known good devices, it should be "good devices" and this part of the documentation should explain what is a good audio device for Jamulus ?
And other important points to note (If I've missed something else) and then point to the community page.
So, no need a dedicated page IMHO, but should be in "requires" paragraph in Getting Started.
And as the server is not the cause of most issues with Jamulus, that's the same for the soundcard, it depends of the host capacities. eg. I've tested my new SSL2+ on macOS, Ubunutu 20.10 (PC), Raspberry Pi4 8 Gb RAM (will test soon on Windows), work's verry well "out of the box" with the three. But on the Rpi, to avoid dropouts and other issues, i need to run ONLY Jamulus. If i open a browser for look at the chords of the song, sound went bad.
The most issues are, on Linux, if the manufacter doesn't follow standard for USB Audio or don't provide spec for the Firewire or TB device if a driver is needed. And on Windows with ASIO as I can see.
But if there is a community page, this page should be structured.
Even if this page move on the community section, I can do the work as a good starting point and as examples for how to list your device.
it should be "good devices" and this part of the documentation should explain what is a good audio device for Jamulus ?
That's a really good idea.
What we could do would be to maintain a small list which focuses on general suggestions (ASIO Driver, Sample rate,...) and a only a hand full of recommend "first start", cheap devices. And then link to a big page (which is searchable for devices) in the Knowledge Base.
And then link to a big page (which is searchable for devices) in the Knowledge Base.
I have finished with the original page and the french version. So, we wait? Or I submit the changes with a PR?
I don't know that? We haven't agreed yet.
I don't know that? We haven't agreed yet.
You said above Yes. This looks much more structured!
So, I've worked on that. But if the structure of the site/wiki change with a community section, I think it is not necessary to propose an update for the actual 'Sound-Devices" page.
Yes, I did say this. And I still think a structure like that is great.
But we haven't agreed if we want to use two pages or one page.
But we haven't agreed if we want to use two pages or one page.
The page I worked on is the actual Sound-Devices page, to be submitted to the changes
branch.
That's my question: do I submit the PR, or it is better to wait the decision about one or two pages?
If you've already worked on it I'd suggest to open a pr (since we can always close/modify it). Since it's English, I suggest gilgongo to review this pr.
@gilgongo @ann0see @trebmuh
You can take à look at the #169 opened this morning (draft on changes
).
Current status of this:
Name of device Description
Windows: Works/doesn’t work
macOS: Works/doesn’t work
Linux: Works/doesn’t work
Additional notes.
Not 100% sure if removing the li was right, but it broke the layout for me (especially on new lines)
We now have a short description on the Getting started page about "good devices". We don’t talk about "Allow monitoring signal from computer" etc. @gegeweb any proposals/ideas on this?
Something like should be good:
« We strongly recommend – although you could start without it – to use an audio interface (a box you plug a microphone/instrument into and connect to your PC e.g. via USB) to enjoy higher quality sound with low latency in Jamulus. You can also use a USB microphone. See recommended hardware. It is better if your device allows monitoring of the signal coming back from Jamulus (from the PC, for example). If this is not the case, configure Jamulus (or JACK) to send the signal to the computer's headphone output. »
a box you plug a microphone/instrument into and connect to your PC e.g. via USB
What about the PCI, PCI-e, or other sound cards which are very good at providing sound quality too (some are even better) ?
It is better ...
"Why" it is better. Users deserve an explanation of the why here.
What about the PCI, PCI-e, or other sound cards which are very good at providing sound quality too (some are even better) ?
I've just added this
It is better if your device allows monitoring of the signal coming back from Jamulus (from the PC, for example). If this is not the case, configure Jamulus (or JACK) to send the signal to the computer's headphone output
Everything else is already present.
It is better if your device allows monitoring of the signal coming back from Jamulus (from the PC, for example). If this is not the case, configure Jamulus (or JACK) to send the signal to the computer's headphone output
This sentence doesn't explain why "it is better".
"Why" it is better. Users deserve an explanation of the why here.
I think it refers to:
ONLY. LISTEN. TO. THE. SIGNAL. FROM. THE. SERVER!
...which might have to be explained too.
Many people I know (mainly singers) don't follow this advice and therefore we have the "slow down" issue. It is really hard to follow this advice as singer, therefore most of us mute ourselves.
Agreed. It needs to be written here in this very page. It's not a good habit to tell users to do something without saying why, especially when it might encourage them to buy something.
Sound-Devices.md
is the only page I haven't pushed for the French translation. If I understood correctly, this page will be the official page maintained with up-to-date information. A page on the community area will be completed by the users. Right?This page should be more structured to be readable and transmit the information correctly, I would suggest the following (as an example):
Sound Devices
This page lists (thanks to Jamulus users) the audio devices known to work (or not) with Jamulus.
Note: depends on how the device works on your system (Linux, MacOS, Windows, etc.).
You can update it with the information you have. Please indicate the platform(s) you are using!.
Audio devices known to work with Jamulus
USB/USB-C devices
Microphones / DI Boxes
Blue Yeti, USB Microphone
Works well under macOS (there is a check option to disable local monitoring). Works well under Windows 10 with ASIO4All, a bit more latency than under macOS. You can disable local monitoring by going deep into the settings.
Latency is good under Linux. You can't disable local monitoring (or we haven't found out how to do it, feel free to send us the information if you know how to do it).
Shure X2u, USB to XLR audio interface with headphone jack connector that converts a wired microphone to a USB microphone.
Set the PC/Mix dialog box to 100% PC to listen to Jamulus' mix on the headphone output.
Tested with a Raspberry Pi 4 under Raspberry Pi OS Buster, kernel version 4.19.
Audio interfaces / digital mixing consoles
Works great out of the box, almost better than under macOS, with Jamulus under Linux Ubuntu 20.04 (ACER Veriton N, i5, 8GB Ram) with these settings (plugged on a USB3 port), recognized as "SSL2+" by
qjackctl
, no or very low latency, very good sound (SSL preamplifier!).Same under macOS on a Mac Mini (late 2012, i7 / SSD / 8Gb RAM), with more sound dropouts than under Linux (plugged on a USB2 Hub).
Not yet tested on Windows 10, native ASIO driver
The monitoring of the Jamulus mix is done by moving the "MONITOR MIX" completely to the right to "USB". See the official manual.
…
Amp modelers/effects pedals for instruments
See Remote Jam with Helix and Jamulus for settings on a Mac.
…
Digital recorders
…
Firewire devices
Works perfectly with Jamulus under macOS (not yet tested on Big Sure). Assign the individual inputs in Jamulus or the corresponding inputs to a stereo auxiliary mix (to be patched in "Universal Control") if more than two channels. Use outputs 17-18 to monitor the Jamulus mix.
These devices work under Windows, they should work with Jamulus under this OS (not tested).
Not tested under Linux, may (or may not) work, see here.
…
Thunderbolt devices
This device provides the lowest latency.
…
Internal soundcards
HiFiBerry DAC+ ADC, Raspberry Pi compatible HAC internal sound card.
Virtually no jitter and good latency (20 milliseconds). No headphone amp, so you'll need one. Used with a mini console Rolls MX122. Tested on Raspberry Pi 4 under Raspberry Pi OS Buster, kernel version 4.19.
Soundblaster Live!, PCI sound card With kX ASIO driver
…
Audio devices known not to work with Jamulus
Zoom B3, USB amplifier modeling pedal for bass. Does not support 48 KHz.
Line6 Bass POD, USB amplifier modeling pedal for bass. Does not support 48 KHz.